¿Cuáles son las ventajas de usar una sobre la otra? Sé que las clases de POCO son más óptimas, pero ¿valen la pena el exceso? ¿Y deberíamos estar siempre usando POCO o hay un momento en el que debería preferir las clases de marco de entidades?POCO Vs Entity Framework Generated Classes?
Las clases predeterminadas EF todas heredan de la clase base EF, mientras que POCO no (de ahí el nombre). Al heredar de la clase base EF, la lógica detrás del seguimiento de cambios está oculta y toda la lógica se almacena dentro del contexto que contiene referencias a sus objetos. Esto es preferible si está trabajando en un estado conectado, es decir, tiene contexto al mismo tiempo que tiene entidades. Este suele ser el caso donde construyes un cliente 'gordo', por lo que el cliente y la base de datos son los únicos dos niveles.
Por otro lado, si trabaja con servicios web/formularios web, las entidades que visita no tienen contexto y tienen que rastrear el estado ellos mismos, entonces el POCO es la mejor opción, ya que tener el objeto de seguimiento de cambios como su propiedad que se puede transferir hasta que decida aplicar los cambios al contexto y guardar. Otro beneficio sería que sus clientes no tienen que ser .NET y no tienen que tener el EF .dll para deserializar sus objetos.
La razón por la que utilizo POCO es la separación de las preocupaciones, es decir, no quiero que mi interfaz tenga que saber cómo funciona mi back-end. Entonces, si quiero cambiar de Linq a Sql a EF o N Hibernate, no tengo que modificar mi código de interfaz.
Utilice POCO si desea una arquitectura limpia, un acoplamiento flexible y una capacidad de prueba máxima.
Si no te importan esas cosas, entonces no las uses.
Personalmente, esas son las cosas más importantes en cualquier aplicación (especialmente una que se requiere mantener durante un largo período de tiempo), por lo tanto, siempre uso POCO.
Teniendo esto en cuenta, los POCO requieren la implementación de algún tipo de mecanismo de seguimiento de cambios, lo que puede ser complicado. Pero es una instalación de una sola vez, y vale la pena el esfuerzo.
Tengo esta lógica en una DLL personalizada que comparto entre proyectos, así que no tengo que seguir haciéndolo una y otra vez.
Para obtener más información acerca de por qué POCO de son importantes en el sentido general (no EF/.NET específica), ver mi respuesta here.
mirada a los artículos siguientes:
Por qué no simplemente representar a su "poco" con una interfaz que sus clases de EF generados pueden aplicar? Entonces, su UI (o servicio de nivel superior) puede lograr un acoplamiento flexible y comprobabilidad solo trabajando en las definiciones de la interfaz en su lugar ... Y no habrá necesidad de escribir/ejecutar funciones de conversión. – Reddog
@Reddog - Bueno, mi ensamblado POCO no tiene referencias a 'System.Data.Entity', no depende de EF. Si usa clases generadas por EF, su biblioteca de clase quedará "ligada" a EF. Si deseo pasar a otro ORM (o DAL), puedo reutilizar mis clases de POCO. Lo mismo no puede decirse con las clases generadas por EF. No se trata solo de un acoplamiento flexible de * otros * proyectos, sino de un acoplamiento flexible entre el POCO y el propio Entity Framework. Permite un verdadero "modelo de dominio". – RPM1984