Consejos para un principiante Sobre las aplicaciones N-Tier

Question

Bien, esta es otra para usted:

Estoy empezando en el mundo de las aplicaciones n-tier. He leído algo sobre el tema y el consejo general es que el objetivo de las aplicaciones n-tier es abstraer la funcionalidad de las capas intermedias. Por lo tanto, en base a esto, en una aplicación de n niveles del modelo regular es:

Data Access -> Business Layer -> Presentation

Como yo soy un desarrollador .NET, pensé que para mejorar la integración con múltiples tipos de clientes (Silverlight, aplicación web o incluso un cliente de WinForms) Debería usar WCF (Windows Communication Foundation) como servicios de datos en la capa de negocios para que los clientes puedan comunicarse con él, independientemente de su tipo. Además, soy un gran admirador de NHibernate como ORM. Así que mi estructura es la siguiente:

Data Access (NHibernate) -> Business Layer (WCF) -> Presentation (WPF, ASP.NET, WinForms

Bueno, por lo que es la configuración. Soy un novato total en este tipo de enfoque, así que pensé que podría publicar aquí solicitando asesoramiento sobre esta configuración. Además, estoy muy confundido sobre cómo configurar esto en una solución VS, me gusta separar capas en diferentes proyectos, pero ¿qué pasa con la abstracción de objetos de datos (como Cliente, Orden, etc.)? ¿Los pongo en una biblioteca separada? ¿Y qué hay de WCF? Sé que es un pecado del programador transferir las clases de datos por cable al cliente. ¿Cuál es la forma del profesional para lograr esto?

Gracias, cualquier consejo sería muy apreciado.

Answer 1

Eso es más o menos el objetivo. Sin embargo, N-Tier es un poco más complejo que N-Layer, y se puede contrastar al preguntar: "¿Sus capas realmente viven en servidores físicos separados?"

Dependiendo de qué tan compleja sea su capa de Negocio, es posible que desee abstraerla más entre una capa de Negocio y Servicio. Normalmente, esos dos están atados muy de cerca y viven en el mismo servidor físico. La capa de servicio a menudo actúa como una fachada para su BLL.

Si su capa de presentación está en el mismo servidor, entonces sus aplicaciones ASP.NET o WinForms pueden querer comunicarse con el BLL sin pasar por los servicios de WCF.

Lea en Microsoft Patterns & Practices - Application Architecture Guide.

Sus objetos de Dominio deben vivir en su propio ensamblaje, generalmente su modelo de dominio. De acuerdo con Microsoft Framework Design Guidelines, es una buena práctica para nombrar sus montajes de proyectos en consecuencia:..

[la empresa] [ProductOrComponent] [...]

resulta que como este formato del nombre de espaciamiento y generalmente utilizan:

....

[la empresa] [Producto] [capa] [subcapa] [...]

he aquí un ejemplo de solución mediante carpetas de soluciones para organizar cada proyecto:

I En este ejemplo, tengo una capa BLL y de servicio. La capa de Servicio proporciona la implementación real en una Biblioteca WCF mientras que la Presentación contiene realmente la aplicación web WCF para alojar los servicios. Siempre es una buena práctica dividir la implementación de la interfaz.

La carpeta/Client se puede ignorar, solo la uso como una aplicación de consola de muestra para probar.Cualquier aplicación cliente que consuma su servicio probablemente debería tener su propia solución o va a administrar una gran solución.

En cuanto a su objeto de datos que se transfiere a través del cable ... Supongo que se refiere a las clases de su ORM. (Modelo de dominio) Estás en lo correcto, generalmente se considera una mala práctica. La solución está utilizando Objetos de transferencia de datos. Puedes ver en la imagen que tengo una biblioteca .Dto. Sin embargo, si puede usar herramientas como AutoMapper, entonces estoy de acuerdo, agregar DTO a su solución conlleva una mayor complejidad y mantenimiento. Creo que Dino Esposito escribió un buen artículo sobre el tema. Trataremos de encontrarlo para ti.

Espero que esto ayude.

---

[EDIT]

Debo señalar, estoy familiarizado con las capacidades de NHibernate. Puede haber mejores soluciones para usar ese ORM. Solo he trabajado con Entity Framework.

---

[EDIT 2]

Salida de Dino Esposito - The Pros and Cons of Data Transfer Objects