"POCO" es un término vago en el espacio ORM. La gente lo usa para significar:
- "POCOS" POCO, que no cambian el seguimiento, la carga diferida, tienen propiedades privadas, etc. Puede ser un reto trabajar con ellos.
- Proxies Psuedo-POCO: los tipos con todo
public virtual y que tienen diferentes tipos en tiempo de ejecución.
- Entidades de seguimiento automático. No POCO, pero tampoco
EntityObject.
puedo encontrar la definición "no depende de un marco externo" a ser algo de auto-servicio. Es una forma de ignorar las limitaciones de un marco. Es decir, los proxies no son POCO reales en mi libro, pero cumplen con esa definición.
¿Qué pasa con EntityObject? No mucho. Es bastante liviano, y es parte de .NET. Está en el perfil del cliente .NET 4, incluso. Ni siquiera te encadena a la FE. Aunque sería un poco extraño usarlo como un "tipo de POCO" con un marco diferente, funcionaría muy bien. Sin embargo, no está en Silverlight, IIRC.
Las entidades POCO son más difíciles de manejar, porque se pierden las cosas que EntityObject le dan de forma gratuita. Eso no es mucho, sino algo a tener en cuenta antes de elegir POCO solo porque "son geniales", especialmente para aquellos que son nuevos en EF.
Una cosa que muchas personas que se vuelven religiosas acerca de las POCO tienden a ignorar: El mapeo de tipos no POCO de ninguna manera lo limita a exponer esos tipos no POCO externamente. Sus servicios de datos puede proyectar asignada tipos no POCO en unmapped dtos POCO y se puede elegir sólo a exponer esos tipos, es decir:
public IEnumerable<FooDto> IFooRepository.SelectAll()
{
return from f in Context.Foos
select new FooDto { Id = f.Id, Name = f.Name };
}
Así cartografía de tipos y tipos de servicios de datos pueden ser fácilmente diferentes preocupaciones, si así lo desea .
¿Cuándo es absolutamente necesario que no EntityObject tipos de mapeo? Bueno, si necesita entidades de seguimiento automático, entonces es un caso abierto y cerrado. Si debe exponer sus tipos mapeados a Silverlight, claramente también.
Más allá de eso, está menos claro. Si está escribiendo un servicio de datos para consumo público, entonces no debe hacer que los DTO sean subtipos EntityObject, porque eso obstaculizaría el camino de conectar un marco diferente más adelante. Nunca haría una interfaz pública inmutable, dependiente de cualquier marco, incluso uno incluido en .NET. Por otro lado, como dije antes, puede exponer un tipo y asignar otro; no hay ningún requisito para exponer los tipos mapeados, nunca, y a menudo muy buenas razones para no exponerlos (tal vez contengan datos no públicos).
Me gustaría agregar que he estado usando POCO ahora principalmente para poder agregar anotaciones de datos a mis propiedades, algo que no creo que sea sensato hacer en el archivo de diseñador de EF ya que podrían ser atacadas cuando se actualiza Aunque probablemente debería utilizarlos en mis Modelos de visualización, es más fácil para la mayoría de mis necesidades agregarlos directamente en el POCO. – JasperLamarCrabb
@CannibalCorpse: las clases de EF son parciales y no es necesario modificar el código generado automáticamente. No hay problema con el uso de DataAnnotations con EF, solo tiene que usar clases de metadatos. – LukLed