¿El uso tradicional del controlador en MVC conduce a una violación del Principio de Responsabilidad Individual?

Question

Wikipedia describe la Single Responsibility Principle esta manera:

La Responsabilidad Individual principio establece que cada objeto debe tener un único responsable, y que la responsabilidad debe ser encapsulada en su totalidad por la clase. Todos sus servicios deben estar estrechamente alineados con esa responsabilidad.

El uso tradicional del controlador en MVC parece llevar a un programador a una violación de este principio. Tome un controlador de libro de visitas simple y vea. El controlador puede tener dos métodos/acciones: 1) Índice() y 2) Enviar(). El índice() muestra el formulario. El Submit() lo procesa. ¿Estos dos métodos representan dos responsabilidades distintas? Si es así, ¿cómo entra la Responsabilidad Individual para jugar?

Answer 1

Sí lo hace.

Y si desea seguir el SRP, desagregue su Controlador en un Dispatcher y Acciones; el Dispatcher distribuye control a sus acciones, y en tiempo de compilación (plantillas de C++) o en tiempo de ejecución (Java XML, lo que sea), debe componer despachadores y acciones.

¿Por qué no vemos esto más a menudo? Debido a que los controladores a menudo son implementaciones "ad hoc", clases concretas a nivel de hoja que no están generalizadas y no están destinadas a ser subclasificadas. Aquí, la clase se usa más para agrupar convenientemente el código, las acciones son, casi con seguridad, no públicas (probablemente privadas, tal vez protegidas), "simplemente" detalles de implementación interna.

La elección de cómo decidir qué acción enviar, el número y la diversidad de acciones posibles, es alta, y el despacho y la acción están estrechamente relacionados. Entonces, en la práctica, a menudo es más fácil juntar el código en un solo lugar.

Answer 2

No, no es así.

No hay nada inherente al patrón MVC o sus variaciones que conducen a una violación del principio de responsabilidad única. Si la implementación de un controlador infringe o no a SRP se basa en si el comportamiento encapsulado tiene más de un motivo para cambiar (al igual que cualquier otra clase), no debido a ningún uso prescriptivo presupuestado del patrón.

El ejemplo que presenta es un subconjunto de formularios básicos sobre la aplicación de datos, donde el controlador simplemente está proporcionando operaciones CRUD para un modelo dado. Las operaciones de CRUD son bastante cohesivas por naturaleza, por lo que generalmente no constituye una violación de SRP. Donde tener múltiples métodos en un solo controlador comienza a ser sospechoso es cuando los métodos representan diferentes interacciones de comportamiento en todo el dominio.

Dicho esto, incluso si alguien dónde argumentan que CRUD representa cuatro preocupaciones no cohesivos separadas, no hay nada inherente al patrón MVC que te obliga a facilitar a cada una de estas acciones dentro del mismo controlador.

Para obtener un poco de historia sobre el patrón MVC, así como un poco de discusión de su aplicación en el desarrollo web, pago Interactive Application Architecture Patterns.