Entity Framework FAQ: Arquitectura y Patrones (es-ES)
Volver al EF FAQ tabla de contenido
¿Entity Framework admite objetos de entidad responsable para guardar cambios propios (en vez de un método central ""Save"" en el contexto del objeto)?
Esto es algo que consideramos pero al final rechazamos en favor del patrón más amplio de la "unidad de trabajo" donde puede realizar cambios en una serie de objetos relacionados y, a continuación, guardarlos todos a la vez. Esto resulta especialmente útil cuando se están modificando las relaciones entre las entidades o realizar cambios en varias entidades que desee en una sola transacción. Podría hacer gestión de transacciones manuales de cualquier manera, pero las transacciones predeterminado que Entity Framework suministra cubren un gran número de escenarios. Usted podría, con algún trabajo, mantener una referencia de sus entidades de vuelta al contexto del objeto que van con y añadir un método Save a las entidades, pero todavía sería guardar todos los cambios pendientes en el contexto, por lo probablemente sería confuso y propenso a errores. Esto es un área que no apoyamos directamente, pero argumentos pueden hacerse para cualquier enfoque.
¿Entity Framework tiene el apoyo a la "Ignorancia de Persistencia"? ¿Qué es la ignorancia de persistencia? ¿Qué es POCO? ¿Qué es IPOCO?
Definiciones:
Ignorancia de persistencia es el término general de cuánto conocimiento deben tener los objetos de la capa de persistencia. En este caso hablamos principalmente sobre la "ignorancia completa de persistencia," que es un paso más allá de POCO en el sentido de que puede crear un conjunto de objetos de dominio donde esa Asamblea no tiene referencia a una persistencia de la pila y, a continuación, simplemente agregando una pequeña cantidad de código y configuración en el exterior pueden persistir los objetos.
POCO es, básicamente, la idea de tener objetos CLR llano que no tiene requisitos especiales para trabajar con una pila de persistencia como el EF. En la práctica esto significa principalmente que no requieren que los objetos heredan de una clase base concreta y no requieren que implementan una interfaz determinada. Muchos sistemas podrían decirse admitir POCO pero aún requieren algo como atributos en las clases o en otras cosas para ayudar a transmitir información a la pila de persistencia. Sin embargo, el punto es que el dominio de objetos no tienen que cambiar sustancialmente para apoyar la persistencia, por lo que son menos contaminantes para acceso remoto a otros niveles, es más fácil cambiar a otra pila de persistencia en una fecha posterior, etc..
IPOCO es un subconjunto de POCO que dice que los objetos no tienen que heredar de una clase base concreta pero que obtenga algún beneficio de la aplicación de determinadas interfaces o incluso pueden ser necesarios implementar las interfaces.
Clases prescriptivas o clases generadas representan el otro extremo del espectro. En estos escenarios, las clases normalmente se heredan de una clase base concreta que trabaja directamente con la capa de persistencia. En muchos casos las clases son generados automáticamente desde un modelo de algún tipo y los usuarios pueden ampliarlas mediante clases parciales o similares. Preceptivas clases tienen la desventaja de ser más ligada a la capa de persistencia, pero tienden a tener ventajas a la hora de rendimiento, así como proporcionar un conjunto más amplio de servicios que los desarrolladores de aplicaciones de lo contrario tendría que escribir ellos mismos.
El EF comenzó como un marco que sólo admite clases prescriptivas. Basado en comentarios de los clientes decidimos que sería muy importante apoyar un mayor grado de ignorancia de la persistencia de algunos escenarios, pero también creemos que los prescriptivas clases son excelentes para otros escenarios.
EF 4 admite ignorancia completa de persistencia (como POCO). Esto significa que puede utilizar objetos CLR "llanura de edad" (POCO), tales como objetos de dominio existentes, con el modelo de datos. Estas clases de datos POCO, que se asignan a las entidades que se definen en un modelo de datos, pueden ser en una Asamblea que no tiene referencias a cualquier Asamblea de Entity Framework, y apoyar la mayor parte de la misma consulta, insertar, actualizar y eliminar comportamientos como tipos de entidad que se generan por las herramientas de Entity Data Model. Para obtener más información, consulte trabajando con entidades POCO 
.EF)
3.5 SP1 admite clases prescriptivas y IPOCO. Es decir, puede tener clases que no se heredan de una clase base de EF, pero deben implementar determinadas interfaces y deben tener atributos específicos para trabajar con el EF. Para obtener más información, consulte aplicación personalizada clase Interfaces de datos (Entity Framework) .
¿Debo utilizar mis entidades EF como mis objetos de negocio o dominio o debo tener clases separadas para mi capa de persistencia y mi negocio?
Esta es una pregunta que no tiene respuesta clara. Por un lado, la EF (especialmente ahora que es compatible con la ignorancia de persistencia) está diseñado para hacer esto posible en una forma que no fuera al no utilizar tecnología O/RM porque la capa de asignación del EF te da una abstracción para ayudar a aislar a sus entidades de la base de datos. Por otro lado, algunos argumentan que si bien esta separación es útil no sea suficiente para aislar completamente a sus entidades o que al menos podría introducir objetos de transferencia de datos (o DTOs) si decide exponer un servicio web en lugar de fluir sus entidades en todo el camino a un nivel diferente.
Para más información consulte este debate en el Stack Overflow .