Mejores prácticas para la arquitectura MVC [cerrado]

28

Mi pregunta es más sobre cómo diseñar una aplicación MVC. Por ejemplo, se nos recomienda usar DI con el patrón Repository para desacoplar el acceso a datos desde el controlador, sin embargo, se dice muy poco sobre CÓMO hacerlo específicamente para MVC. ¿Dónde colocaríamos las clases del repositorio, por ejemplo? No parecen estar relacionados específicamente con el modelo, ya que el modelo también debería estar relativamente desacoplado de las tecnologías de acceso a datos reales.

Una segunda pregunta implica cómo estructurar las capas o niveles. La mayoría de las aplicaciones de ejemplo (cena Nerd, Music Store, etc.) parecen usar un enfoque de 2 capas de un solo nivel (sin contar las pruebas) que generalmente tiene controladores que llaman directamente al código L2S o EF.

Si quiero crear una aplicación de varios niveles / capas, ¿cuáles son algunas de las mejores prácticas en lo que respecta a MVC?

Erik Funkenbusch
fuente

Respuestas:

5

La DI se realiza en ASP MVC utilizando una fábrica de controladores. Esta fábrica se utiliza para resolver las dependencias de su controlador.

MvcContrib tiene algunas implementaciones de Controller Facotry que puede usar de inmediato. Uso su implementación Castle Windsor y funciona bien. También sugeriría revisar su clase TestHelper. Tiene una funcionalidad muy buena para burlarse del controlador HTTPContext, Sesiones, etc. MVCContrib

Personalmente, me gusta dar a mis modelos una instancia de repositorio para trabajar. El modelo expone una API al repositorio (CRUD). La dependencia del controlador en un modelo particular se inyecta en la creación (constructor), esto se inyecta a través de la fábrica de controladores. Este es mi punto de entrada al gráfico de objetos que gestiona mi contenedor IoC.


fuente
2

¿Dónde colocaríamos las clases del repositorio, por ejemplo?

Pertenecen al modelo; son el modelo en la aplicación.

¿Cómo hago para estructurar las capas? Si quiero crear una aplicación de varios niveles / capas, ¿cuáles son algunas de las mejores prácticas en lo que respecta a MVC?

Niveles Representan separaciones físicas de código. Las capas representan separaciones lógicas. Las capas (como lo son actualmente) funcionan bien para MVC. Dependiendo de la cantidad de lógica de negocios, puede colocarse en su Controlador, o puede colocarse en un ensamblaje separado y puede ser utilizado por el controlador durante el ciclo de solicitud.

George Stocker
fuente
¿Estás sugiriendo que deberían ir al Proyecto de IU de una aplicación de varios niveles?
Erik Funkenbusch
@Mystere Man Si no es gigantesco, entonces deberían ir al proyecto que aloja su aplicación MVC. Específicamente, la lógica de negocios iría al controlador y cada acción tendría su propia lógica. MVC no es solo un patrón de interfaz de usuario único; Es por eso que no estoy de acuerdo con su afirmación de que es un 'proyecto de interfaz de usuario'. No lo es Es un proyecto MVC que, como Viewsección (está su interfaz de usuario).
George Stocker
Ok, tal vez lo expresé mal. Sin embargo, ¿no está de acuerdo con que la capa de vista no debería manipular la base de datos? Y si coloca las clases Repository en el modelo, entonces la vista puede hacerlo.
Erik Funkenbusch
en una aplicación Small MVC, la "capa" de la interfaz de usuario es simplemente la carpeta que contiene las vistas. En una aplicación más grande, podría ser su propio proyecto. Si es su propio proyecto, entonces se coordinaría con el controlador, y el controlador podría conectarse al BusinessLayer según sea necesario. Nadie fuera del controlador ni siquiera necesitaría saber que existía la capa empresarial. Creo que automáticamente piensas que estos están en proyectos separados, pero no tienen que estarlo.
George Stocker