N-Layer Architecture

Question

Estoy en la situación de que tengo que diseñar e implementar un sistema desde el principio. Tengo algunas preguntas sobre la arquitectura en las que me gustaría que comentaran y pensaran.

Información rápida sobre el proyecto: Es una aplicación web centrada en datos.

La aplicación se basará en Microsoft .NET Framework 4.0 con la base de datos MS SQL SERVER 2008.

Requisito:

1. Rich UI y robusto
2. El soporte multi-dispositivo (todos los navegadores y en todos los dispositivos) acoplado
3. sin apretar

A continuación se muestra el diagrama de arquitectura que he construido :

informativa de la arquitectura

1. Capa de presentación: HTML5/ASP.NET MVC + jQuery (aplicación web para el apoyo de múltiples dispositivos en la primera versión)
2. Servicios Distribuidos: WCF (XML/JSON/JSONP)
3. Capa de dominio (Business Layer): toda la lógica de negocio
4. Persistencia de datos (capa DAL): Entity Framework 4.0 con el primer enfoque de base de datos. entidades POCO se generan y se separan usando la plantilla T4
5. capa infraestructural: Contiene las bibliotecas comunes como entidades POCO, manejo de excepciones, el registro etc

mis preocupaciones:

1. Como aplicación se va a construir vagamente acoplado por lo que en el futuro si los requisitos del negocio crecen, los nuevos módulos se pueden enchufar fácilmente sin afectar la arquitectura. Así que pensó en utilizar el patrón de repositorio junto con la COI y DI (puede haber unidad/Ninject/Sprint.NET o cualquier otro)
2. WCF tanto con Soporte de XML y JSON
3. distribuida capa de servicios para colocar COI & DI
4. manejo de excepciones & las anotaciones utilizando Enterprise Library 5,0

Buscando valiosos comentarios y sugerencias. Si estoy haciendo algo mal, por favor ponme en la dirección correcta.

Answer 1

Tiene sentido que las IU de WPF, WinForm etc. llamen a la capa WCF. Supongo que es un requisito empresarial tener varias UI; de lo contrario, si solo puede tener una UI, una IU web receptiva es la opción más flexible.

Sin embargo, no creo que su UI MVC necesite usar la capa WCF. Podría llamar a la capa de dominio directamente. Eso sería más rápido y eliminaría una capa sin sentido.

Obviamente, eso sólo funcionará siempre y cuando no se pone ninguna lógica en su capa de WCF. Y la capa WCF realmente no debería tener lógica.

También afirman que desea colocar COI & DI en la Capa de Servicio Distribuida. Eso no tiene mucho sentido en términos de su UI de MVC. Tendrá que usar DI en el proyecto MVC para que pueda probar los controladores por separado.

Answer 2

¿Cómo es que el diagrama de la arquitectura no utiliza la capa de dominio para ASP.NET?

Me parece que es posible que se overarchitecturing su aplicación. Además, si bien es bueno admitir 6 (más o menos) diferentes tecnologías de front-end, el esfuerzo por mantener todas ellas será horrendo. Me quedaría con una tecnología para el front-end, probablemente HTML5 con MVC del lado del cliente o similar.

Answer 3

que sugeriría el siguiente comentario: desde el principio de su enfoque creará estrecho acoplamiento. Esto va directamente en contra de su requerimiento # 3 "débilmente acoplados"

En el diagrama se han definido dos módulos. Módulo principal y Módulo 2. Supongo que estos dos módulos son bastante distintos entre sí. Lo que quiero decir con esto es que podría desarrollarlos completamente por separado y luego enchufarlos, porque las preocupaciones comerciales que abordan son diferentes.

Sin embargo, su enfoque arquitectónico actual:

• Parejas Módulo principal y el módulo 2 los datos en la misma base de datos
• Parejas módulo principal y el módulo 2 objetos de negocio en la misma capa de negocio
• Parejas Módulo principal y servicios del Módulo 2 en la misma capa de servicio
• Parejas del despliegue y la administración del Módulo principal y el Módulo 2

Lo que puede valer la pena considerar: Construir módulo principal y el módulo de servicio 2 pilas verticales separadas.

Lo que quiero decir es el módulo principal y el módulo 2 se convierten en Servicio Principal y Servicio 2

Cada servicio tiene su propia base de datos, que es propia capa de negocio, que es la capa propios servicios y su propio componentes de interfaz de usuario.

Sin embargo, esto plantea la preocupación: ¿cómo puede Servicio y 2 Principal ambos trabajan juntos para crear mi producto?

Para hacer frente a esto:

1. Al final interfaz de usuario, la puntada su extremo delantero juntos mediante el uso de código de cliente para cargar las respuestas del servicio principal y de servicio 2 en una sola vista.

2. En el extremo posterior se utiliza publicar suscribir mensajería para permitir que el servicio principal para suscribirse a los eventos que suceden en servicio 2 y viceversa.

Esto resultará en una aplicación construida desde la base en la parte superior de las pilas del servicio vertical débilmente acoplados, que mantienen la consistencia por el intercambio asíncrono de mensajes.

Si luego necesita agregar un nuevo módulo a su aplicación, puede crear una nueva pila de servicios que admita la capacidad deseada y conectarla con poco o incluso ningún cambio necesario para las otras pilas (idealmente la única razón cambiar las pilas existentes sería que quieren suscribirse a eventos del nuevo módulo).

Es una aproximación muy diferente a la que está sugiriendo, pero que le permite cumplir mejor con el requisito de acoplamiento flexible, en mi opinión.

Answer 4

En cuanto a su diagrama Tengo un par de puntos no me queda claro en:

• ¿Dónde está el modelo de dominio? Domain Core o el 'modelo' en la capa de persistencia?
• ¿Cómo interactúa la capa de dominio con la capa de acceso a datos? La interacción no es tan clara como entre la capa de servicio/aplicación y la capa de dominio.
• ¿Cuál es la diferencia entre un repositorio en la capa de dominio y un repositorio en la capa de acceso a datos? Normalmente hago la distinción de tener "repositorios de modelos" en la capa de dominio que actúan sobre los objetos de modelo de dominio y "puertas de enlace de datos" en la capa de acceso a datos que actúan sobre los DTO.
• ¿Qué es el núcleo del dominio? ¿Es esta la implementación de las transacciones de la capa de aplicación?
• ¿Debe haber una mayor abstracción del marco de persistencia? (EF)