2009-05-27 10 views
30

Tengo una aplicación ASP.NET que utiliza una arquitectura en capas, p. capa de presentación, capa de lógica de negocios, capa de acceso a datos.ASP.NET y Entity Framework en Layered Architecture: utilizando Entity Framework para ORM solo

No quiero que la capa empresarial tenga que saber nada sobre cómo se implementa la capa de acceso a datos y no estoy buscando vincular la Entidad directamente a un control de datos usando EntityDataSource ni nada por el estilo. (Así que un escenario de patrón de repositorio)

ESTOY BUSCANDO UTILIZAR EL MARCO DE ENTIDADES COMO UNA HERRAMIENTA DE ORM PARA GENERAR CLASES. Yo sé cómo hacer esto. Lo que no tengo claro es

  1. ¿Es aconsejable propagar estas clases a través de la aplicación para que la capa de lógica de negocios se ocupe de las clases parciales creadas directamente por el marco de entidades? (por ejemplo, si tengo una tabla de clientes en sql, la entidad fw crearía una clase de cliente que podría usarse potencialmente en todas las capas de mi aplicación)
  2. Cómo administrar el soporte de transacciones si mi BLL llama a varias clases de entidades diferentes sino que quiere tratar como una transacción

Respuesta

9
  1. Si usted es práctico: Sí! Evitará el trabajo de mapeo doble y los posibles errores generados por el mapeo doble. (Por doble mapeo quiero decir DB -> ORM y ORM -> lógica de negocios).
  2. Use TransactionScope. Es la mejor forma de realizar transacciones sin preocuparse por las transacciones anidadas.
0
No

con marco de la entidad, pero había tratado de crear una muestra con dos procedimientos de inserción almacenado siendo ejecutados por separado en la capa de acceso de datos (usando bloque de aplicación de acceso de datos 3.1), envuelto dentro de contexto TransactionScope en Servicio/BLL, No funcionó. Se pasó una inserción, otra falló y los datos se cometieron.

¿Tuvo usted algún éxito al hacerlo usted mismo?

2

Otra forma de hacerlo es utilizar clases de correlacionador, usar EF como acceso a datos y usar las clases EF generadas solo dentro del DAL, luego mapear estos objetos DAL a los objetos de su BLL a través de mapeadores. Funciona bien para nosotros.

1

Ahora con el nuevo EF4 también puede utilizar las clases de POCO, eliminando así la carga adicional de mapeo de las entidades entre las capas. En nuestra aplicación, usamos EF4 y utilizamos entidades comerciales en la aplicación, además de ver qué modelo de vista requería. Dio un impulso significativo en el rendimiento.

0

Incluso si utiliza clases de POCO generadas, como las otras operaciones están sugiriendo, igual tendrá que mantener una cierta dependencia del marco de entidades: las consultas que envía a su DbContext/ObjectContext. Por lo tanto, debería considerar encapsular las consultas en los repositorios.