Mejores prácticas para la organización de proyectos con ASP.NET MVC

Question

Recientemente descargué la excelente ASP.NET Storefront reference application de Rob Conery y la encuentro increíblemente instructiva. Una pregunta que viene a la mente es dónde se deben ubicar las clases de modelo (y las clases de datos de las que dependen). La plantilla del proyecto MVC crea una carpeta de modelo. Pero me parece que sería mejor romper el modelo en un ensamblaje de proyecto separado para que pueda ser reutilizado por otras aplicaciones potenciales (por ejemplo, herramientas de administración relacionadas con el dominio de la aplicación del sitio web).

Tengo curiosidad por conocer las opiniones de las personas.

Answer 1

Realmente depende del tamaño del proyecto. No tiene ningún valor inherente tener un ensamblaje de "modelos" por separado, ya que puede probar un proyecto de aplicación web (incluidos los proyectos de MVC).

Answer 2

Estoy de acuerdo. A menos que la aplicación solo sea la única aplicación web, la dividiría en un proyecto separado. Normalmente tendré un front end de aplicación web que usa uno o más servicios de Windows para realizar tareas automáticas recurrentes (enviar cargos, enviar notificaciones, etc.) y una o más herramientas de aplicación de consola para aprovisionar la base de usuarios de aplicaciones de nuestro directorio empresarial - mis aplicaciones son típicamente aplicaciones de intranet que pueden aplicarse solo a subconjuntos de toda nuestra población de usuarios. Tener los modelos (capa de datos) en un proyecto separado me permite compartirlo fácilmente con todas las demás aplicaciones.

Answer 3

Si sus modelos son Objetos de transferencia de dominio, tenerlos en un ensamblaje separado le permitirá reutilizarlos. Si su aplicación es una simple aplicación de MVC, y eso es todo, o simplemente lo está haciendo para la prueba de la unidad, no es necesario. De lo contrario, podría:

• ¿Ha capa de servicio Web utiliza el conjunto de modelos para pasar los objetos del modelo de la aplicación MVC para su uso en su aplicación. Esto sería necesario si practica no permitir que las aplicaciones web tengan acceso directo a la base de datos. En ese caso, es posible que tenga un mvc que llame a un servicio web para autenticar y extraer los datos.

• Tiene la intención de crear otras aplicaciones utilizando los mismos modelos, como las herramientas de administración que mencionó.

Espero que ayude. En una nota lateral, es posible que desee poner sus piezas "comunes" en su propio marco, que incluiría "modelos" (entidades, objetos de dominio, el nombre que desee).

Answer 4

¡Conjuntos independientes! = Acoplamiento flojo.

Answer 5

Me gusta tener proyectos separados para mi modelo, acceso a datos y lógica de negocios. También tengo interfaces en cada capa. Esto hace que las pruebas con los simuladores sean fáciles de implementar, mantiene mi código organizado y mantiene mis controladores a la luz. Si coloco todas las capas en la carpeta de modelos, no me sentiría lo suficientemente organizado (solo una cuestión de personalidad). También me gusta tener la opción de exponer servicios web para mis aplicaciones, por lo tanto, esto hace que todos los mismos sistemas lógicos, modelos y acceso a los datos estén disponibles para esos servicios.

Answer 6

A veces puede tener sentido tener una carpeta de Modelos en su proyecto de sitio web MVC Y tener un proyecto separado para almacenar modelos de datos también. (aunque esto podría tener sentido si tienes una plataforma bastante grande en la que estás trabajando con otros proyectos que reutilizan bibliotecas comunes).

Un ejemplo se ve así:

Proyectos:

• transversales: contiene todas las interfaces comunes para la transferencia de datos de objetos a su alrededor entre otros servicios, así como las operaciones relacionadas con la seguridad y las clases

• Negocio: contiene operaciones y objetos de la capa de negocios, controla el acceso a las operaciones a través de las demandas de seguridad (las entradas y salidas solo utilizan las interfaces de corte cruzado).

• de datos: contiene los modelos de datos para acceder a datos de otros servicios/bases de datos (utilizados por el proyecto de negocios)

• WebAPI: (proyecto MVC) contiene una carpeta Modelos. Algunos objetos modelo pueden ser compuestos de las interfaces CrossCutting para admitir operaciones web RESTful de máxima eficiencia (por lo tanto, una única llamada HTTP a la API web pero puede dar como resultado múltiples llamadas BLL).