Organización de la solución ASP.NET MVC

Question

Estoy buscando crear un proyecto ASP.NET MVC a bastante gran escala y quiero separarlo para que no sea todo en un proyecto y un ensamblaje.

Miré cómo Oxite hace su organización (http://oxite.codeplex.com/Wiki/View.aspx?title=architecture), pero me preguntaba cómo otras personas lo hacen también. ¿Alguna sugerencia?

Actualmente, estoy pensando en algo muy similar a Oxite:

Proyecto - Este proyecto contiene la capa del modelo que incluye los modelos, clases de configuración e interfaces de servicios y repositorios. Aquí no debería haber mucha lógica de aplicación, principalmente estructuras de datos.

Project.Core - Este proyecto contiene todo el código para el controlador y el enrutamiento, incluidos los filtros y los resultados. También se incluye aquí el modelo ViewData.

Project.Site - Este proyecto contiene las vistas, imágenes, javascript y todos los demás archivos estáticos sin código. Aquí debería haber un código mínimo de C#, la mayoría debería vivir en Project.Core

Answer 1

Es posible que desee comprobar cómo S#arp Architecture tiene sus controladores, servicios y núcleo divididos en proyectos con los proyectos de prueba correspondientes.

Answer 2

Así es cómo hemos roto el proyecto. Este ASP.NET MVC está a punto de ser lanzado y hemos aprendido algunas cosas en el camino. También di los motivos por los que cada proyecto está separado.

Project.Models - The M en MVC, esto contiene todas sus clases de negocios. Si puede administrarlo (lo que realmente debería hacer), no debería haber clases relacionadas con la persistencia o el servicio web aquí. Por supuesto, puede tener interfaces para el acceso a datos definidas en este proyecto. Una manera rápida de verificar si este proyecto está "limpio" de acceso a datos es comprobar si necesita referencias a DLL de acceso a datos como NHibernate en este proyecto o no. Motivo: En teoría, debería ser capaz de vincular este proyecto y utilizar estas clases en cualquier otro lugar, incluso si se cambia a una interfaz de usuario diferente, como una consola etc.

Project.Site - Este proyecto contiene toda tu JavaScript, CSS, Vista, etc., todo lo relacionado con la Vista. Motivo: Si tiene un diseñador de sitio web, puede darle acceso a este proyecto y hacer que trabaje lejos.

Project.Controllers - La C en MVC, esta contiene todos sus controladores y sus ModelBinders. Motivo: Tres proyectos diferentes para Modelos, Vistas y Controladores dificultan la aparición de problemas.

Project.Tests - Mantener todas las pruebas unitarias en las fuerzas de proyectos separados que únicamente para probar interfaces públicas; una buena práctica para pruebas unitarias en mi opinión.

Projects.Services - Todos los servicios web, código relacionado con la persistencia van aquí en este proyecto.

Por ahora, las clases de utilidades entran en Project.Models, pero creo que sería mucho mejor tener una solución separada para las clases de utilidades y simplemente importarlas como referencias a ensamblados compilados cuando sea necesario.