ASP.NET MVC: ¿debería existir lógica empresarial en los controladores?

Question

Derik Whitaker publicó un artículo hace un par de días que llegó a un punto que tenía curiosidad aproximadamente por algún tiempo: ¿debería existir lógica empresarial en los controladores?

Hasta ahora, todas las demostraciones de ASP.NET MVC que he visto ponen acceso al repositorio y lógica empresarial en el controlador. Algunos incluso lanzan validación allí también. Esto resulta en controladores bastante grandes, hinchados. ¿Es esta realmente la forma de usar el marco MVC? Parece que esto terminará con una gran cantidad de código duplicado y lógica distribuida en diferentes controladores.

Answer 1

La lógica de negocios debería estar realmente en el modelo. Deberías apuntar a modelos gordos, controladores flacos.

Por ejemplo, en lugar de tener:

public interface IOrderService{
    int CalculateTotal(Order order);
}

Prefiero tener:

public class Order{
    int CalculateTotal(ITaxService service){...}        
}

Esto supone que el impuesto es calculado por un servicio externo y requiere que su modelo sepa sobre las interfaces a sus servicios externos.

Esto haría que su controlador se vea más o menos así:

public class OrdersController{
    public OrdersController(ITaxService taxService, IOrdersRepository ordersRepository){...}

    public void Show(int id){
        ViewData["OrderTotal"] = ordersRepository.LoadOrder(id).CalculateTotal(taxService);
    }
}

O algo por el estilo.

Answer 2

Me gusta el diagrama presentado por Microsoft Patterns & amp; Prácticas . Y creo en el adagio "Una imagen vale más que mil palabras".

Answer 3

Esta es una pregunta fascinante.

Creo que es interesante que una gran cantidad de aplicaciones MVC de muestra realmente no sigan el paradigma MVC en el sentido de colocar verdaderamente la "lógica empresarial". enteramente en el modelo. Martin Fowler ha señalado que MVC no es un patrón en el sentido de Gang Of Four. Más bien, es un paradigma que el programador debe agregar patrones a si están creando algo más allá de una aplicación de juguete.

Entonces, la respuesta corta es que " lógica empresarial " de hecho, no debe vivir en el controlador, ya que el controlador tiene la función adicional de tratar con la vista y las interacciones del usuario y queremos crear objetos con un solo propósito.

Una respuesta más larga es que necesita pensar un poco en el diseño de la capa de su modelo antes de simplemente mover la lógica del controlador al modelo. Quizás pueda manejar toda la lógica de la aplicación usando REST, en cuyo caso el diseño del modelo debería ser bastante claro. De lo contrario, debe saber qué enfoque utilizará para evitar que su modelo se hinche.

Answer 4

Puede consultar este increíble tutorial de Stephen Walther que muestra Validar con una capa de servicio .

  

Aprenda cómo mover su validación   lógica fuera de las acciones de su controlador   y en una capa de servicio separada. En   este tutorial, Stephen Walther   explica cómo puedes mantener   separación de las preocupaciones por el aislamiento   su capa de servicio desde su   capa de controlador.

Answer 5

Business Logic no debe estar contenido en los controladores. Los controladores deben ser lo más delgados posible, lo ideal es seguir el patrón:

1. Buscar entidad de dominio
2. Ley de entidad de dominio
3. Preparar datos para ver / devolver resultados

Además, los controladores pueden contener cierta lógica de aplicación.

Entonces, ¿dónde pongo mi lógica de negocios? En modelo.

¿Qué es el modelo? Ahora esa es una buena pregunta. Consulte el artículo sobre patrones y prácticas de Microsoft (felicitaciones a AlejandroR por su excelente hallazgo). Aquí hay tres categorías de modelos:

• Ver modelo : Esto es simplemente una bolsa de datos, con una lógica mínima, si es que hay alguna, para pasar datos desde y hacia las vistas, contiene validación de campo básica.
• Modelo de dominio : modelo fat con lógica empresarial, opera en una o varias entidades de datos (es decir, la entidad A en un estado dado que la acción en la entidad B)
• Modelo de datos : modelo compatible con el almacenamiento, la lógica contenida dentro de una sola entidad se relaciona solo con esa entidad (es decir, si el campo a luego el campo b)

Por supuesto, MVC es un paradigma que viene en diferentes variedades. Lo que describo aquí es que MVC ocupa solo la capa superior, vide este artículo en Wikipedia

  

Hoy en día, MVC y el modelo-vista-presentador similar (MVP) son patrones de diseño de Separación de Preocupaciones que se aplican exclusivamente a la capa de presentación de un sistema más grande. En escenarios simples, MVC puede representar el diseño primario de un sistema, llegando directamente a la base de datos; sin embargo, en la mayoría de los escenarios, el Controlador y el Modelo en MVC tienen una dependencia suelta de un nivel o nivel de servicio o de datos. Esto es todo sobre la arquitectura Cliente-Servidor

Answer 6

Si usas inyectores de dependencia, la lógica de tu negocio irá hacia ellos y, por lo tanto, obtendrás controladores limpios y ordenados.