Esto es algo similar a esta pregunta pero más amplio.
En general, con ORM como EF 4.1 que admite POCO, ¿tiene sentido que sus entidades de dominio sean los objetos que persisten en su base de datos?
Con ORM anteriores como EF 4 o Linq-to-SQL, sus "objetos de base de datos" se generaron automáticamente y se unieron estrechamente a su base de datos, por lo que, para aplicaciones no triviales, se asignaron a entidades de dominio inteligentes más robustas antes de ser Poner a trabajar.
¿Es la idea con los ORM más nuevos simplemente construir entidades de dominio robustas y luego tener una capa de datos que simplemente proporcione un mapeo entre dichas entidades de dominio y su DBMS?
Al escribir, tengo la sensación de que este siempre ha sido el objetivo, pero que no es posible (fácilmente) con las herramientas disponibles, al menos no en el mundo .NET.
fuente
Respuestas:
Creo que el objetivo general de los ORM es que la base de datos esté asignada directamente a objetos de dominio, que son idealmente POCO. Así que la respuesta a tu pregunta es sí. Ahora que EF es capaz de mapear a POCO, es ideal considerar esas POCO como entidades de dominio. Para otros ORM como NHibernate, esto ha sido posible por un tiempo y creo que la gente generalmente los ha estado utilizando como tal.
Pero este objetivo de tener entidades de dominio directamente asignadas a la base de datos no siempre se puede lograr. Hay algunos casos en los que se necesita una traducción significativa entre la base de datos y el modelo de dominio. El ORM puede no ser capaz de hacer la traducción. En este caso, es posible que desee una capa de POCO intermedios que se asignan con el ORM a la base de datos y luego una capa de traducción que los convierte en POCO de dominio y viceversa.
fuente