asp.net-mvc - net - que es razor en español
¿Es mejor tener controladores enormes o muchos controladores en MVC? (7)
Estamos construyendo una aplicación de recursos humanos bastante grande en ASP.NET MVC, y hasta ahora nuestros controladores se están volviendo bastante grandes. Por ejemplo, tenemos un controlador de empleado y se incluyen todas las vistas de los empleados (información personal, deducciones de empleados, dependientes, etc.). Cada una de estas vistas puede tener múltiples acciones o subvistas (por ejemplo, CRUD). Cada acción es relativamente pequeña, pero los controladores pueden tener docenas de funciones.
¿Hay alguna mejor práctica para dividir los controladores? En lugar de tener un controlador de Empleado con docenas de vistas, ¿sería mejor tener un controlador para cada subtipo (es decir, EmployeePersonalInfoController, EmployeeDeductionController, EmployeeDependentController)?
Y finalmente, ¿importa?
Aclaración actualizada
Mi preocupación original era con las acciones de CRUD. Por ejemplo, consideremos Crear y Eliminar ...
Acciones actuales en EmployeeController :
CreateEmployee()
DeleteEmployee()
CreateEmployeeDeduction()
DeleteEmployeeDeduction()
CreateDependent()
DeleteDependent()
etc.
Si los controladores estaban divididos:
EmployeeController
Create()
Delete()
EmployeeDeductionController
Create()
Delete()
EmployeeDependentController
Create()
Delete()
EmployeeBenefitController
Create()
Delete()
etc.
En el primer escenario, nuestras ~ 100 pantallas se dividen en 8-10 controladores grandes. En el segundo, probablemente tendría ~ 50 controladores.
¿Por qué no agruparlos?
Tener una estructura como,
employee/payroll/
employee/payroll/giveraise
employee/payroll/manage401k
employee/general/
employee/general/address
employee/general/emergencycontact
Ahora puede tener un controlador de nómina manejando las acciones relacionadas con la nómina y un controlador general que maneja los detalles regulares de un empleado.
En mi humilde opinión, si mantiene el código en sus controladores, entonces realmente no importa.
La mayoría de tu código estaría sucediendo en una capa de negocios en algún lugar ¿verdad? Si ese es el caso, entonces todo lo que realmente está haciendo en su controlador es devolver datos a la vista. Como debería ser.
No estoy seguro de si soy partidario de separar los controladores en subtipos. Si bien debe mantener la separación de las preocupaciones, creo que los subtipos van demasiado lejos.
Puede echar un vistazo a esta publicación para ver si ayuda. Mismos vistas diferentes caminos
Esa puede ser una solución mejor que usar un enfoque de subtipo que sugirió.
Los controladores están destinados a ser contenedores para acciones en un contexto. IE, un controlador de cliente tendría acciones relacionadas con el control de clientes. Esto es particularmente adecuado para CRUD. Me gustaría ir con menos controladores más grandes por esta razón. Dicho esto, depende de ti, como arquitecto de aplicaciones, elegir la forma que mejor se adapte a tu código y simplemente porque es más común hacerlo de una manera no significa que tengas que hacerlo.
Si tiene grandes cantidades de código, le sugiero que busque áreas ASP.NET MVC. Puede encontrar excelentes publicaciones al respecto aquí en el blog de Scott Gu y aquí en el blog de Steve Sanderson . Si tiene tantos controladores, podría ser adecuado para usted.
Solo pensé en volver a leer su publicación, sospecho que su ejemplo no se acerca al nivel de complicación que tiene en su código. Tal vez podría ser útil si publicó una situación en la que no estaba seguro de si era o no una buena idea dividir el controlador que es más específico (y menos CRUDO, porque CRUD es bastante sencillo).
No me gustaría tener 50 controladores. En este momento tengo 16 en mi aplicación y se siente bien. Si tiene 50 controladores, también tendrá 50 carpetas de nivel para las vistas. Será difícil encontrar la vista y el controlador que necesita para trabajar. Como otros mencionaron, las acciones suelen ser cortas y no es tan malo tener un par de ellas en su controlador.
Traté de tener 1 controlador por parte del sistema. Defino una parte del sistema tomando el esquema de mi base de datos y dibujando una línea alrededor de las tablas que pertenecen juntas.
Organizaría los controladores más o menos en torno a los casos de uso y su agrupación lógica. Por ejemplo, si tiene múltiples casos de uso administrativos / de tipo de recursos humanos que probablemente estén disponibles para un grupo limitado de personas, agrupe aquellos en un controlador. Otros controladores podrían organizarse alrededor de objetos de modelos de dominio específicos, por ejemplo, administración de permisos de autoservicio, consultas salariales, etc. No hay una regla rígida, hay que crear un equilibrio entre no poner demasiada responsabilidad en un único controlador vs. estructuras internas.
Recuerde también que, en la medida de lo posible, no debe tener una lógica comercial central en sus controladores. Realmente implementan el comportamiento del front-end, mientras que las reglas del sistema real deben estar en su modelo de dominio y capa de servicio. Mientras mantenga las cosas aproximadamente dentro de la capa correcta y razonablemente desacopladas, no puede ir demasiado mal con la forma en que coloca las operaciones individuales dentro de sus controladores.
Otro enfoque que hemos estado utilizando es tener un ControllerBase para mantener las preocupaciones transversales en un lugar común para las operaciones de CRUD. Este controlador declara las operaciones comunes e incluye puntos de extensión para las cosas específicas de la entidad. Tuvimos demasiadas duplicaciones de código sin algo como esto.
Luego, heredas este controlador y creas uno por entidad. Y sí, hay muchos controladores pero teniendo tantas pantallas, no creo que sea el problema principal.
La mayoría de las acciones aceptan un Modelo complejo y jugamos con las carpetas modelo para eliminar el desorden de los controladores. Puedes ver una buena publicación sobre eso here .
Entonces, usar áreas como @Odd sugiere que es una buena idea, al menos separar las vistas, porque cuando las tienes muchas es un desastre.
Afortunadamente ASP.NET MVC v2 nos traerá áreas y encapsulando vistas en diferentes ensamblajes (en realidad eso se puede hacer ahora extendiendo la clase VirtualPathProvider).
Las clases parciales le permiten extender su clase a través de múltiples archivos. De esta forma, puede agrupar las áreas relevantes de su controlador en archivos separados y, sin embargo, todas seguirán siendo parte del mismo controlador. p.ej
EmployeeDeductionController.cs
public partial class EmployeeController
{
public ActionResult Deduct()
{
}
// etc
}
EmployeeBenefitController.cs
public partial class EmployeeController
{
public ActionResult GiveBenefit()
{
}
// etc
}