Arquitectura MVC: ¿Cuántos controladores necesito?

Para tu ejemplo, crearía dos controladores:

• Sessions Controller para inicio de sesión y cierre de sesión (crear y destruir sesión para REST como diseño)
• Controlador de archivos para todo lo que hay en los archivos (índice = buscar y crear = cargar)

En general, un enfoque REST donde piense en todo como un recurso que se puede mostrar, crear, editar y destruir le da una buena idea de cómo estructurar las cosas. Como puede ver en mis ejemplos, no me quedo demasiado cerca de cada verbo en REST.

Lo más probable es que necesite más controladores para una mayor funcionalidad. Por ejemplo, un controlador de usuarios donde los usuarios pueden crear nuevas cuentas. Y además, necesitará una interfaz de administración donde pueda editar los recursos con privilegios más altos. En tal caso, es bastante común que se dupliquen casi todos los controladores.

Una estimación muy aproximada para obtener una idea inicial podría ser un controlador para cada tabla en su base de datos a la que los usuarios pueden acceder. Pero esto es realmente solo una medida muy cruda.

Realmente depende de la aplicación web. En tu ejemplo, uno es probablemente suficiente. Si tuviera que implementar una aplicación de comercio electrónico completa con envío, impuestos, administración de inventario, precios escalonados, etc., es posible que desee tener un par más.

Si su controlador sufre de uno o más código huele (especialmente Gran clase u objeto de Dios ) entonces sabrás que probablemente ya has pasado el punto en el que solo uno lo hará.

Realmente depende de las necesidades de la aplicación y la arquitectura de los módulos empresariales.

Una regla general general , el número de controladores necesarios depende de una serie de módulos y submódulos en la aplicación web.

Como complemento, sería útil organizar los controladores en Áreas . El concepto de Areas se incluye en el MVC de ASP.NET marco y simplifica la organización de los controladores que sirven un módulo.

Hay una serie de discusiones relacionadas:

• MVC Architecture
• Diseño de acciones del controlador MVC de ASP.NET
• organización de directorios de Vista y controlador de mvc
• ¿Cómo se ve la organización de clase MVC para múltiples vistas y controladores?

Me gusta la forma en que Apple lo hace.

  

Cada vista está controlada por un solo controlador de vista.   ~ Ver la Guía de programación del controlador para iOS

La idea es que deberías poder intercambiar fácilmente Vistas. En mi opinión, al tener solo un 1 Controller por View hace que sea más fácil lograr esto. Pero estoy seguro de que podrías tener un Controlador con múltiples Vistas y aún así diseñarlo para que puedas cambiar de Vistas sin cambiar la lógica del programa.

Un ejemplo que me gusta es pensar en un termostato. Un termostato es un gran visual para ver el patrón MVC.

En un termostato analógico antiguo, puedes imaginar cosas como esta:

Ver : el lector de temperatura, que muestra la temperatura actual.

Controlador : el dial, donde cambia la temperatura

Modelo : las partes internas invocadas por el controlador que hacen que la temperatura cambie.

Siempre debe respetar los diseños que permiten el acoplamiento suelto y limitar los modelos y sus controladores asociados a una sola tarea , y debe usar tantos módulos / controladores como necesite . Dependiendo del tamaño de su aplicación, es posible que tenga muchas menos vistas que modelos y controladores. Esto es de esperar con cualquier aplicación de gran tamaño. La buena programación orientada a objetos se caracteriza por acoplamiento suelto, encapsulación, herencia y polimorfismo. No todos los idiomas admiten el polimorfismo en el mismo grado (función, método, sobrecarga / anulación del operador).

Si desea comprender mejor cómo emplear adecuadamente la arquitectura MVC, consulte los "Patrones de diseño: elementos del software reutilizable ... de GoF", que utiliza C ++ y SmallTalk para el código de ejemplo. Este libro no es el alfa y el omega, ¡pero ciertamente es un comienzo!

¡Buena suerte!

Supongo que su ejemplo evolucionará hacia un sistema complejo.

Solicitud:

El usuario inicia sesión:

• LoginController

Es su responsabilidad exclusiva manejar los inicios de sesión, redirigir o notificar al usuario del resultado.

Subir un archivo

• UploadController

Supongo que aquí desea cargar cualquier tipo de archivo. Si en una fecha posterior decides subir archivos MP3 y PDF, entonces tendré un UploadController base, MP3UploadController y PDFUploadController.

Buscar un archivo.

• SearchFileController

Esto sería suficiente para un requisito básico. Puede tener varios controladores de búsqueda en una fecha posterior, según la complejidad de la lógica de búsqueda. Lo último que desea tener es un único controlador de búsqueda con 20 métodos de acción que realizan diferentes búsquedas.

Cerrar sesión.

- LogoutController .

Uno podría considerar que esto es una exageración, pero no creo que lo sea. Creo que está limpio y bien separado.

Si observara la estructura de este proyecto, sabría de inmediato qué hace y cómo está estructurado. Para ir un paso más allá, pondría LoginController y LogoutController en un área separada.

He desarrollado algo como esto antes y funcionó muy bien.

La mayoría de su código estaría sucediendo en una capa de negocios, ¿no? Si ese es el caso, entonces todo lo que realmente está haciendo en su controlador es devolver los datos a la vista.

No estoy seguro si soy un fanático de separar los controladores en subtipos. Si bien debe mantener la separación de las preocupaciones, creo que los subtipos van demasiado lejos. También debe tener cuidado en los casos en que los objetos pesados se inicializan en el constructor o en un controlador. Por ejemplo: en su ejemplo, querría un objeto pesado, utilizado solo para liberar / cargar el archivo cuando el usuario está en la página de inicio de sesión.

Es mejor tener un controlador por unidad lógica, por ejemplo, AccountController (inicio de sesión, registro, cierre de sesión), FileController (búsqueda, carga), etc.

En general, puede decir que cada MODELO tiene sus propios CONTROLADORES y VISTAS dedicadas. Al decir general, quiero decir que esta es la mejor práctica.

los aspectos de la aplicación (como la administración de usuarios) deben traducirse al servicio de la aplicación y deben ser llamados por el controlador mismo, o envolver su controlador (utilizando atributos que hacen que la funcionalidad del controlador sea "visible" según el rol del usuario solicitado, por ejemplo) instancia).

Recuerde que todos los controladores deben manejar básicamente las operaciones CRUD sobre el modelo y usar diferentes vistas para diferentes filtros.

En mi opinión, una de las principales ventajas de MVC como patrón es que ofrece la mejor manera de vincular modelos y vistas.

Sobre el ejemplo que agregaste: Me gustaría crear 2 controladores: uno para la operación de inicio de sesión de todos los usuarios (registro, inicio de sesión, cierre de sesión, etc.) y el segundo para las operaciones de archivos (Cargar y buscar). tenga en cuenta que también se debe hacer una copia de seguridad del primero con algún aspecto relacionado con la funcionalidad de inicio de sesión y el segundo es un controlador ordinario