¿Debo usar clases parciales como capa empresarial cuando uso el marco de entidad?

Question

Estoy trabajando en un proyecto utilizando el marco de la entidad. ¿Está bien utilizar clases parciales de las clases EF generadas como la capa empresarial? Estoy empezando a pensar que así es como se pretende utilizar EF.

He intentado utilizar un patrón DTO y pronto me di cuenta de que solo estoy creando una serie de clases de mapeo que duplican mi esfuerzo y también un motivo para más trabajos de mantenimiento y una capa adicional.

Quiero usar auto-tracking-entities y pasar las entidades EF a todas las capas. Por favor comparte tus pensamientos e ideas. Gracias

Answer 1

No haría eso. Intenta también mantener las capas lo más independientes posible. Por lo tanto, un pequeño cambio en el esquema de su base de datos no afectará a todas sus capas.

Las entidades se pueden utilizar para la capa de datos pero no deberían. En todo caso, proporcione las interfaces que se utilizarán y permita que sus entidades las implementen (en el archivo parcial) el BL no debe conocer las entidades sino las interfaces.

Answer 2

Creo que la clase parcial será una buena idea. Si el modelo se regenera, no perderá la lógica comercial en las clases parciales.

Como alternativa, también puede consultar el código EF4 solo para que no necesite generar su modelo desde la base de datos.

Answer 3

Yo no haría eso, por las siguientes razones:

1. de que pierda la clara distinción entre la capa de datos y la capa de negocio
2. Esto hace que la capa de negocio más difíciles de probar

Sin embargo, si tiene algún código específico de modelo de datos, coloque esa clase parcial para evitar que se pierda cuando vuelva a generar el modelo.

Answer 4

Utilizaría clases parciales. No existe la capa de datos en el código DDD-ish. Hay un nivel de datos y reside en SQL Server. El código de la aplicación solo debe contener la capa empresarial y algunas asignaciones que permiten objetos empresariales persistentes en el nivel de datos mencionado.

Entity Framework es su código de acceso a datos, por lo que no debe crear el suyo propio. En la mayoría de los casos, el esquema de la base de datos se modificaría porque el modelo ha cambiado, no lo contrario.

Dicho esto, me gustaría desanimarlo para que comparta sus entidades en todas las capas. Valoro la separación de la interfaz de usuario y la capa de dominio. Usaría DTO para transferir datos dentro y fuera del dominio. Si tengo la libertad necesaria, incluso usaría el patrón CQRS para deshacerme de las entidades de mapeo en DTO. Simplemente crearía un segundo proyecto de acceso a datos de EF destinado solo a leer datos para la IU. Se construiría sobre la misma base de datos. Lees datos a través del modelo de lectura (anemic - without business logic), pero lo modificas emitiendo comandos que se ejecutan contra el modelo real implementado usando EF y métodos parciales.

¿Responde a esta pregunta?

Answer 5

Eché un vistazo al uso de clases parciales y descubrí que exponer el modelo de la base de datos hacia la capa UI sería restrictivo.

por varias razones:

1. El modelo entidad creada incluye un profundo modelo de objeto relacional que, dependiendo de su esquema, sería exponerse a la capa de interfaz de usuario (decir el presentador de MVP o el modelo de vista en MVVM)
2. La capa lógica de negocios normalmente expone operaciones contra las que puede codificar. Si ve un método de guardado en el BLL y mira los parámetros necesarios para guardar y ve un modelo que requiere la construcción de otras entidades (causa de la naturaleza relacional del modelo de entidad) solo para guardar, no se está guardando la operación simple.
3. Si tiene un grupo de servicios web, los datos adicionales deberán enviarse sin ganancia aparente.
4. Puede crear DTO's más inmutables para sus parámetros de operación en lugar de encontrar efectos secundarios porque la misma instancia fue modificada en alguna otra parte de la aplicación.

5. Si utiliza TDD y sigue YAGNI, tenderá a tener una estructura diseñada específicamente para la operación que está escribiendo, con la cual sería más fácil construir pruebas (no necesita crear otros objetos no relacionados con la prueba solo porque están en el modelo). En este caso es posible que tenga ...

   public class Order 
   { ... 
       public Guid CustomerID { get; set; } 
   ... } 
   

En lugar de utilizar el modelo Entidad generada por la EF que tienen referencias expuestas ...

public class Order 
{ ... 
    public Customer Customer { get; set; } 
... } 

De esta manera el ID del cliente solo se necesita para una operación que toma una orden. ¿Por qué necesitaría construir un Customer (y potencialmente otros objetos también) para una operación que se ocupa de tomar pedidos?

Si usted está preocupado acerca de la duplicación y la cartografía, a continuación, echar un vistazo a Automapper