none
Controlador para Plan de pago. RRS feed

  • Pregunta

  • Buenas tardes,

    Estoy desarrollando una aplicación en MVC con C#.

    En mi aplicación, se puede generar un plan de pago de un préstamo, algo así:

    El plan de pago es una tabla que detalla las cuotas que debe de pagar el cliente por un préstamo.

    Bueno, tengo claro que necesito un controlador llamado PlanPagoController, y uno de sus métodos se llamará CargarPlanPago() y ese me recuperará, por ejemplo, el plan de pago de la captura que muestro arriba.

    Ahora bien, el usuario debe de ser capaz de agregar o editar cada item de ese detalle, o sea cada cuota del plan de pago; esto es lo que no tengo claro, la pregunta es: en mi PlanPagoController podría tener un método AgregarCuotaPlanPago() o EditarCuotaPlanPago() o estos métodos deberían de ir en otro controlador que podría llamarse CuotaController?

    Saludos,


    Carlos Márquez
    San Pedro Sula
    Honduras

    viernes, 22 de julio de 2016 0:24

Respuestas

  • hola

    >>en la lógica de negocios puedo utilizar el FlujoCajaModelo?

    que es el FlujoCajaModelo ? porque solo has mencionado PlanPagoModelo

    >>mas bien éste modelo y esta entidad deberían de llamarse CuotaEntidad y CuotaModelo?

    los nombres dependen de lo que representen para el negocio

    entiendo que un Plan de Pago tendra una lista de cuotas que permitan cumplirlo y todo esto permite cumplir un prestamo

    seguramente la entidad prestamo la tienes definida ya que incluye los datos de la persona fisica o empresa a la cual se realiza este prestamos y demas datos

    ahora este podria tener una lista que cuotas, ya que el plan de pago sea un concepto virtual y no deba representar, o sea todas las cuotas son el plan de pagos

    esto que menciono son temas de negocio y cambia segun como quieras modelarlo

    saludos


    Leandro Tuttini

    Blog
    MVP Profile
    Buenos Aires
    Argentina

    viernes, 22 de julio de 2016 15:55

Todas las respuestas

  • Plantéalo al revés: dado que lo que más trabajo te llevará es la edición del plan de pago (las cuotas), empieza por hacer un CuotasController que puedes generar inicialmente con los automatismos de Visual Studio para que te proporcione la funcionalidad básica para añadir, borrar y modificar registros. Una vez generado automáticamente, si quieres puedes luego "pulirlo" a mano.

    Y después de eso, te faltará el método que "inicializa" los valores de la tabla (el que crea el plan de pagos). Este es un único método que, si quieres, puedes incorporar a ese mismo controlador que ya tienes. O, si te gusta más, puedes crear un nuevo controlador para ubicar en él este método. Normalmente la decisión la tomarás en función de las Urls que quieras aplicar, por ejemplo, si lo quieres llamar con misitio/cuotas/generar, pues entonces lo meterías dentro del controlador de cuotas.

    viernes, 22 de julio de 2016 6:07
  • hola

    >>en mi PlanPagoController podría tener un método AgregarCuotaPlanPago() o EditarCuotaPlanPago()

    depende, la idea es editar sobre el mismo grid dodne listas los valores, o tendrias un link o boton que llevara a otro view donde editaras los valores ?

    Si es en la misma lista seguro necesites algun action que recibe el POST con la lista de cuotas y debe validar cuales actualizar

    Ahora si vas a generar view diferentes donde editar los valores de la lista entonces necesitaras action que reciben el GET (el el id de la cuota que editas) y el POST (con la entidad de la cuota para realizar la actualizacion o el alta)

    >>estos métodos deberían de ir en otro controlador que podría llamarse CuotaController?

    depende, nuevamente si editas sobre la lsita va todo en el mismo controller, ahora si tienes list y edicion de entidades puede optar por separar en dos controllers, aunque no es obligatorio, podrias crear el listado de plan de pago en un controller y la edicion de una cuota en otro (pero vuelvo a remarcar que no es obligatorio)

    saludos


    Leandro Tuttini

    Blog
    MVP Profile
    Buenos Aires
    Argentina

    viernes, 22 de julio de 2016 13:02
  • Hola, Alberto/Leandro.

    Lo que pretendo hacer es que haya una view para crear, actualizar y eliminar.

    He creado un modelo y una entidad:

    public class PlanPagoEntidad
        {
            public int IdPrestamo { get; set; }
            public int IdCuota { get; set; }
            public DateTime? Fecha { get; set; }
            public decimal SaldoCapital { get; set; }
            public decimal Capital { get; set; }
            public decimal Tasa { get; set; }
            public decimal TasaPonderada { get; set; }
            public decimal Libor { get; set; }
            public decimal Interes { get; set; }
            public decimal Flujo { get; set; }
            public string Estado { get; set; }
        }

     public class PlanPagoModelo
        {
            public int IdPrestamo { get; set; }
            public int IdCuota { get; set; }
            public DateTime? Fecha { get; set; }
            public decimal SaldoCapital { get; set; }
            public decimal Capital { get; set; }
            public decimal Tasa { get; set; }
            public decimal TasaPonderada { get; set; }
            public decimal Libor { get; set; }
            public decimal Interes { get; set; }
            public decimal Flujo { get; set; }
            public string Estado { get; set; }
        }

    Partiendo que voy a tener un CuotaController, en los action de éste y en la lógica de negocios puedo utilizar el PlanPagoModelo? o mas bien éste modelo y esta entidad deberían de llamarse CuotaEntidad y CuotaModelo?

    Saludos,


    Carlos Márquez
    San Pedro Sula
    Honduras


    viernes, 22 de julio de 2016 15:23
  • hola

    >>en la lógica de negocios puedo utilizar el FlujoCajaModelo?

    que es el FlujoCajaModelo ? porque solo has mencionado PlanPagoModelo

    >>mas bien éste modelo y esta entidad deberían de llamarse CuotaEntidad y CuotaModelo?

    los nombres dependen de lo que representen para el negocio

    entiendo que un Plan de Pago tendra una lista de cuotas que permitan cumplirlo y todo esto permite cumplir un prestamo

    seguramente la entidad prestamo la tienes definida ya que incluye los datos de la persona fisica o empresa a la cual se realiza este prestamos y demas datos

    ahora este podria tener una lista que cuotas, ya que el plan de pago sea un concepto virtual y no deba representar, o sea todas las cuotas son el plan de pagos

    esto que menciono son temas de negocio y cambia segun como quieras modelarlo

    saludos


    Leandro Tuttini

    Blog
    MVP Profile
    Buenos Aires
    Argentina

    viernes, 22 de julio de 2016 15:55
  • Hola, Tuttini.

    Perdón, me equivoqué, el término es PlanPago, no FlujoCaja.

    Sí, el plan de pago es un listado de cuotas que deben de cumplirse para saldar el préstamo otorgado.

    Sí, tengo una entidad Préstamo y almacena las condiciones en que se otorgó éste.

    La duda de la entidad es porque a nivel de BD la tabla se llama así, PlanPago.

    Si nos basamos en eso, en que un plan de pago es un listado de cuotas, la entidad que tengo PlanPagoEntidad pasaría a llamarse CuotaEntidad y aun así mantener mi repositorio PlanPago y que estos métodos trabajen con la entidad Cuota?

    nota: no estoy utilizando EF.

    Saludos,


    Carlos Márquez
    San Pedro Sula
    Honduras


    viernes, 22 de julio de 2016 16:09
  • hola

    >>un plan de pago es un listado de cuotas, la entidad que tengo PlanPagoEntidad

    pero entonces un planpago tendria una lista de cuotas

    o sea

    public class PlanPagoEntidad{

      //otras propiedades

      public List<CuotaEntidad> Cuotas {get;set;}

    }

    y el prestamos tendra una propiedad a plan de pago

    igual sigo pensando que el plan de pago no se deberia presentar como entidad ya que es solo un concepto agrupador de cuots, entonces deberia ser

    public class PrestamosEntidad{

      //otras propiedades

      public List<CuotaEntidad> PlanPago{get;set;}

    }

    esto por supuesto es subjetivo, quiza hayas analizado el negocio y pienses que no es asi

    tienes una tabla de cuotas ?

    saludos


    Leandro Tuttini

    Blog
    MVP Profile
    Buenos Aires
    Argentina

    viernes, 22 de julio de 2016 16:19
  • Hola, Tuttini.

    Quiero volver a resaltar que No uso Entity Framework, por lo que No utilizaría el :

    public class PrestamosEntidad{

      //otras propiedades

      public List<CuotaEntidadPlanPago{get;set;}

    }

    Asumo que por eso lo colocaste, corrígeme si estoy mal.

    A nivel de BD No tengo una tabla de cuotas, mi tabla se llama PlanPago y no es mas que un detalle:

    IdPrestamo
    IdCuota
    Fecha
    SaldoCapital
    Capital
    Tasa
    TasaPonderada
    Libor
    Interes
    Flujo
    Estado

    Podría crear una clase CuotaEntidad que contenga los campos anteriores, lo que pasa es que en la BD no existe una tabla llamada Cuota y eso es lo que me genera confusión.

    Creando una clase CuotaEntidad el modelo de negocio tendría un poco mas de sentido pero a nivel de BD no existe esa tabla, aun así podría crear esa entidad con ese nombre? y mantener un repositorio PlanPago que sus métodos usen la CuotaEntidad?

    Saludos,


    Carlos Márquez
    San Pedro Sula
    Honduras

    viernes, 22 de julio de 2016 16:38
  • Hola, Tuttini.

    Podría crear mi entidad CuotaEntidad con estos campos:

    IdPrestamo
    IdCuota
    Fecha
    SaldoCapital
    Capital
    Tasa
    TasaPonderada
    Libor
    Interes
    Flujo
    Estado

    Y para mantener en mi PlanPagoEntidad tener simplemente:

    public class PlanPagoEntidad
    {
    public CuotaEntidad Cuota { get; set; }
    }

    Será válido hacerlo de esa forma? Así tendría mi CuotaEntidad para cuando vaya a editar un item del Plan de pago y tendré también mi PlanPagoEntidad que me servirá para cuando cargue toda la data de ese plan de pago List<PlanPagoEntidad>.

    Será válido?

    Saludos,


    Carlos Márquez
    San Pedro Sula
    Honduras

    viernes, 22 de julio de 2016 17:32
  • >>A nivel de BD No tengo una tabla de cuotas, mi tabla se llama PlanPago

    pero entonces porque defines el id con el nombre CuotaId ? no deberia ser PlanPagoId

    >>Podría crear una clase CuotaEntidad que contenga los campos anteriores, lo que pasa es que en la BD no existe una tabla llamada Cuota y eso es lo que me genera confusión

    claro porque el plan de pagos es un concepto que agrupa cuotas

    >>aun así podría crear esa entidad con ese nombre? y mantener un repositorio PlanPago que sus métodos usen la CuotaEntidad?

    podrias, pero evalua si esto no va a genera problemas en tu desarrollo al tener una table pero mapea con una entidad diferente

    lo que si podrias hacer es crear CuotaEntidad y PlanPagoCollection

    entonces en PlanPagoCollection haces que herede de

    public class PlanPagoCollection : List<CuotaEntidad>{

    }

    cuando

    public class PrestamosEntidad{

      //otras propiedades

      public PlanPagoCollection  PlanPago{get;set;}

    }

    saludos


    Leandro Tuttini

    Blog
    MVP Profile
    Buenos Aires
    Argentina

    viernes, 22 de julio de 2016 19:57
  • >>Y para mantener en mi PlanPagoEntidad tener simplemente Será válido hacerlo de esa forma?

    no, porque el plan de pago es una lista de cuotas

    public class PlanPagoEntidad
    {
        public List<CuotaEntidad> Cuotas { get; set; }
    }


    Leandro Tuttini

    Blog
    MVP Profile
    Buenos Aires
    Argentina

    viernes, 22 de julio de 2016 19:59
  • Hola, Tuttini.

    Últimas preguntas:

    1. Es permitido tener en mi DAL una CuotaEntidad aunque esta no existe en la BD?

     2. Te parece que una salida viable es tener:

    public class PlanPagoEntidad
    {
        public List<CuotaEntidad> Cuotas { get; set; }
    }

    3. En el préstamo he visto que colocas

    public class PrestamosEntidad{

      //otras propiedades

      public PlanPagoCollection  PlanPago{get;set;}

    }

    Esa propiedad no será sólo en caso de trabajar con EF?

    Saludos,


    Carlos Márquez
    San Pedro Sula
    Honduras



    viernes, 22 de julio de 2016 20:47