Arquitectura de tres niveles pregunta

Question

Tengo una aplicación ASP.NET con una arquitectura de tres capas:

• capa de presentación: ASP.NET

• Bussiness capa:. C # biblioteca

• capa de acceso de datos: # biblioteca C con
  ADO.Net objetos de Entity Framework.

Algunos métodos de capa de Bussiness se vuelven objetos de entidad ADO.NET pero, capa de acceso a datos no es visible en la capa de presentación no puedo hacer eso.

Mi pregunta es: En una vista de diseño, ¿Es correcto para exponer objetos de entidad en la capa de presentación? Creo que sólo tengo que vincular la biblioteca capa de datos con ASP.NET aplicación.

Gracias!

Answer 1

Sugiero que usted mira en los conceptos de objetos ... Ver u objetos de transferencia de datos (DTO). Se podría considerar el uso de una herramienta como AutoMapper o similar, lo que creará un objeto de dominio específico vista de sus entidades. En general, es posible que tenga pantallas que necesitan una entidad presente para realizar su trabajo. Pero más a menudo que no tendrá que pasar varias entidades diferentes. En este caso es mejor crear un DTO que contiene todas estas entidades. Al hacer esto va a añadir una capa de separación entre la capa de presentación y la capa de negocio. Muchas veces sus entidades tienen más poder que es posible que desee exponer a su capa de presentación. Y viceversa. Con frecuencia es posible que necesite obtener algunos mensajes de interfaz de usuario a la capa de presentación basada en una cierta validación marcado en su capa de negocio. En lugar de hacer que su interfaz de usuario más compleja de lo que debe ser (mediante introducción de sus entidades completo) sólo se puede pasar en lo que necesita la interfaz de usuario en forma de DTO. Además, nunca hay una necesidad de sus objetos de negocio que se preocupan por nada específico a la capa de presentación. Le sugiero que no databind directamente a algo tan lejana como la capa de acceso a datos. Técnicamente la capa de presentación debe saber lo menos posible sobre su capa de negocio. En el caso de MVP o MVC esto es muy fácil de lograr mediante la desconexión de la parte delantera y la parte trasera por medio de esta separación adicional!

Answer 2

Es absolutamente deseable tener objetos disponibles para el uso y consumo en su nivel de presentación de su entidad. Eso es lo que todo el trabajo es para.

• Encuadernación colección de objetos a una cuadrícula / listview / desplegable
• Salpicaduras de un único objeto (es decir, cliente) en un formulario para lectura / actualizar / borrar

Esto hace la vida más fácil por el momento. De lo contrario, tendría que pasar cadena después int después de doblar después de cuerda entre sus capas de presentación y de negocios.

Estos pueden ser objetos Entity o incluso sus propios objetos POCO que fueron hidratados de los objetos de entidad.

Incluso iría tan lejos como para decir que sus ENTIDADES deben estar en su propia asamblea separar del DAL.

Answer 3

Creo que no, no lo es, la mejor manera de hacerlo es separar las clases de datos de comportamiento, y de referencia únicas clases de datos en la presentación level.The buen enfoque pienso usar WCF ver esta enlace

Answer 4

Ver Supervisar Controller y pasivo Ver

Si pasa la Entidad, está supervisando esencialmente controlador. De lo contrario usted es Ver pasiva.

Supervisar controlador es menos trabajo, pero menos comprobable. Supervisar Controller también dice que el enlace de datos está bien. Ver pasiva es comprobable, pero mucho más trabajo. Sin enlace de datos. Una gran cantidad de propiedades.

Normalmente me quedo con Supervisar Controller. Por lo general, no es necesario que el nivel de la capacidad de prueba y no merece la pena adicional.