ASP.NET MVC con servicio de capa y capa de repositorio, donde las interfaces deben ser definidos?

Question

Estoy en el proceso de determinación de una forma bastante simple de arquitectura de capas para una .NET MVC aplicación que tiene un repositorio de capa y capa de servicio.He encontrado algunas bastante claras y simples ejemplos, en particular www.asp.net, y algunas de las preguntas y respuestas aquí, pero estoy buscando algo que es un poco más sencillo, adecuado para aplicaciones pequeñas, pero que utiliza diferentes proyectos, para transmitir la idea.El ejemplo que he enlazado más arriba tiene el repositorio y servicio de las clases en los Modelos de espacio de nombres.Que no es suficiente de una separación clara para mí ser capaz de ilustrar adecuadamente.

Tengo un proyecto independiente para el repositorio que implementa la interfaz IRepository.Hay un separarate proyecto para el Servicio que implementa IService y toma un IRepository (inyección de constructor).El Servicio implementa IService.Es suficiente para este ejemplo que el controlador de la instancia del servicio, sin necesidad de un contenedor de IoC todavía.Piense en ello como un paso intermedio para la comprensión de las mejores prácticas de arquitectura, parte de una secuencia que se construye progresivamente para incluir la inyección de dependencia y, posiblemente, más capas.

La pregunta es, ¿a dónde debería definir IRepository y IService?Tanto el servicio de repositorio de proyectos necesita hacer referencia a ellos, por supuesto.Parece claro, entonces, que debe ser definido en otro proyecto que se hace referencia por tanto el servicio de repositorio de proyectos.Si es así, ¿qué sería de una buena convención de nomenclatura ser?Algo así como XXXXContracts?

Asimismo, para los modelos de datos transcurrido entre la presentación, el servicio y el repositorio de capas, es aceptable tener un proyecto independiente llamado XXXXModels hace referencia a todas las capas?Entiendo que en algunos casos los modelos pasados entre el servicio y el repositorio de la capa puede diferir de aquellos que se pasan entre el servicio de la capa y la capa de presentación, pero el principio es el mismo.

He encontrado las respuestas a preguntas similares aquí, pero tienden a involucrar a una arquitectura más complicada de lo que he descrito aquí.Estoy buscando lograr un sencillo y limpio ilustración de las dos capas que puede ser visto como un paso o dos por encima referencia a la capa de datos y tener la lógica de negocio en los controladores, eso es todo.Sé que hay una fuerte y argumento válido para ir directamente a la plena mejores prácticas, pero no todo el mundo es apto para hacer que saltar una vaya.

Answer 1

Introducción

Esto es algo que me he preguntado a mí mismo.Una pregunta que siempre tengo es similar a la tuya;

¿qué sería de una buena convención de nomenclatura ser?

¿Cómo debo nombre a las cosas?Deben ir en carpetas o proyectos?

Después de buscar alrededor sospecho que la respuesta es que realmente no importa.Lo importante es que la solución tiene algunas sensible de la arquitectura y que intenta seguir las buenas prácticas, tales como SÓLIDO.

Mi ASP.NET MVC héroes en este tema son Jeffrey Palermo, Steve Smith y Jimmy Bogard.

Cebolla Arquitectura

Jeffrey Palermo describe una combinación de viejas ideas, pero les une y le da visualmente estimulante nombre de Cebolla Arquitectura (se recomienda una lectura).Jeffrey muestra un buen enfoque para el problema de dónde poner las cosas.Él explica que en el centro (o superior) de la aplicación tiene su Core.Esta capa es donde se debe poner interfaces tales como IRepository y IService.

Casi todas las interfaces deben ir en el núcleo y todo lo demás (otros proyectos) puede hacer referencia al núcleo.De esta manera todo lo que sabe de la estructura esquelética de la aplicación sin conocer los detalles de la implementación.

Trate de tener su capa de interfaz de usuario de referencia como poco como sea posible (dentro de lo razonable).En una de mis aplicaciones de mi interfaz de usuario (MVC) de la capa sólo hace referencia al Núcleo.Todo lo que necesita es que le inyecta con La Inyección De Dependencia.

Steve Smith discute la Cebolla de la Arquitectura y de ideas similares, con demostraciones en MVC Solución de las Mejores Prácticas:Una solución para la solución de problema

Mi solución

En mi MVC soluciones tengo una típica estructura como esta:

• MyProject.Core
• MyProject.Dominio
• MyProject.DependencyInjection
• MyProject.Infraestructura
• MyProject.Web
• MyProject.Pruebas

El Core contiene mi interfaces.Es generalmente dividido en carpetas, como el de Servicios, Modelos de Dominio, Repositorios y así sucesivamente.

El Dominio la capa de referencias sólo el núcleo y contiene mi aplicación.Que proporciona una gran cantidad de de la clases concretas para el dominio de la abstracción en el núcleo.Se trata de una gran cantidad de lógica de negocio, procesamiento, control de comandos, gerente de clases, de hormigón implementaciones de servicio y así sucesivamente.Considero que es un bastante del interior de la capa y por lo que las referencias como poco como sea posible.

El DependencyInjection la capa contiene mi escogido DI paquete/marco y los detalles de implementación.Considero que es una capa exterior;similar a la interfaz de usuario o la Infraestructura y así que está bien si se hace referencia a una gran cantidad.No es necesario para esta capa a ser un proyecto independiente y muchas personas te dirán que no lo haga.Eso está bien;hacer lo que funciona para la complejidad de su proyecto.Me gusta mi DI a su propia cosa.Lo bueno de ser tan independiente es que podría reemplazar la DI marco con uno diferente y las cosas iban a estar bien.No hay ninguna capa de referencia de la DI proyecto.

El Infraestructura la capa contiene información acerca del registro, correo electrónico y acceso a datos.Contendrá mi ORM de la elección.No es de negocios de la lógica de las cosas y no de IU cosas.Es el ferrocarril de mi solución para hacer las cosas.Es en la capa exterior, pero sólo hace referencia al Núcleo.

El Web la capa es mi proyecto de MVC y sólo hace referencia al Núcleo.

La complejidad y reflexiones finales

He encontrado las respuestas a preguntas similares aquí, pero tienden a involucrar a una arquitectura más complicada de lo que he señalado aquí

Es un buen punto.Es importante tener en cuenta la complejidad de su problema.Pero no se desanime por buena la solución de las prácticas.Mi solución y la Cebolla Arquitectura no necesariamente son muy complejas y realmente no inflar su solución.Se acaba de separar las cosas.

En Evolutiva De La Estructura Del Proyecto, Jimmy Bogard habla acerca de las cosas más complejas.Si lo que me has dicho me parece demasiado complejo, siga Jimmy consejo y ponerlo todo en un proyecto (su capa de interfaz de usuario).Que bien, como siempre que se adapte a usted.

Recuerde tomar mi solución sólo como una idea - algo a tener en cuenta;mi enfoque es un intento de seguir los sabios consejos de los mejores, pero estoy seguro de que sólo he logrado mucho;Me puede (y debe) mejorar aún.