ASP.NET MVC: ¿Qué pasa donde?

Question

Estoy a punto de comenzar a desarrollar una aplicación ASP.Net MVC de tamaño mediano. Estoy tratando de obtener el diseño correcto. Tengo la intención de tener las siguientes capas:

• capa de interfaz de usuario (MVC)
• servicio de capa
• capa de repositorio de capa
• de acceso a datos

Me va a utilizar la unidad como mi contenedor COI y EF4.1 Code First para acceso a datos.

La aplicación se dividirá en varios conjuntos. Tengo un problema de decidir qué asambleas necesitaré y dónde colocar el siguiente:

• Entidades/objetos de dominio, por ejemplo, Cliente, Factura
• DTOs v.g. CustomerDTO, InvoiceDTO
• Interfaces de servicio, p. ICustomerService
• Interfaces de repositorio, p. ICustomerRepository
• Servicios (clases de implementación de la interfaz de servicio) p. CustomerService
• Repositorios (clases de implementación del servicio de depósito) p. CustomerRepository
• ViewModels, p. CustomerViewModel
• enumeraciones

Mi pregunta es: ¿Cómo se suele dividir la suya y por qué?

Editar: provocado por la respuesta de @ TheHurt.

¿Cómo serían las referencias entre los conjuntos, es decir, qué ensamblaje estaría haciendo referencia a cuál?

Answer 1

Ésta es la forma en que podría hacerle frente:

montaje App.UI:

• ViewModels van en la zona de los modelos.

montaje App.Repository:

• aplicación Resumen de repositorio de hormigón.
• ICustomerRepository

App.Repository.SQL:

• aplicación concreta.
• EFCF POCOs montaje

App.Services:

• servicio abstracto.
• ICustomerService
• dtos

App.Services.Implementation:

• servicio concreto.
• CustomerService

App.Common:

• código compartido.
• enumeraciones

Hay un par de cuestiones que todavía tengo dificultad. Pierdes las anotaciones de datos de EFCF cuando cruzas el límite de servicios. Por lo tanto, debe realizar la validación del lado del servidor o mantener la validación de los modelos de vista en sincronía con las entidades del repositorio. Siente que cuanto más capas hay, más se viola el DRY. Supongo que eso es normal para el curso cuando tus modelos de vista no se asignan directamente a tus entidades. Podría hacer que sus modelos de vista sean sus DTO y lanzarlos al conjunto Común, pero eso parece unir las cosas demasiado estrechamente si tiene la necesidad de ser súper flexible con sus servicios.

EDITAR

Si estás interesado en la integración de WCF en la mezcla es probable que desee crear contratos de datos que están muy cerca del modelo de vista MVC (o utilizar los contratos, según el modelo de vista). Probablemente no expongas eso al mundo ya que el servicio sería específico para esa implementación de tu sitio MVC, activa otro servicio para consumo público. Si está haciendo un servicio WCF, probablemente quiera tener toda su lógica comercial en el servicio, los controladores solo manejarían la lógica de navegación.

Nota al pie, trato de mantenerme alejado del "metal" tanto como sea posible, mientras desarrollo un diseño que me permita separar el código en varias capas en el futuro. Si no puedo explicar con claridad las diversas capas del sistema a mi gerente con una hoja de papel, es muy probable que el diseño sea demasiado complejo. En su mayor parte, todo se verá bonito en Visio si está bien diseñado.

En cuanto a cómo las cosas se referencian entre sí: la interfaz de usuario se referiría al Serivce (o la implementación del servicio, que puede no ser necesario. Simplemente guárdelo todo en el mismo lugar). Service refs the Repository. La implementación del repositorio no hace referencia a nada, ya que está cargado por IOC. Todo refs Común.