c# - lazy - Entity Framework Self-Tracking Entities no recomendado por Microsoft
load collection entity framework (2)
(NOTA: Como no trabajo para MS, esto es una conjetura basada en sus declaraciones públicas y su historia pasada).
El primer artículo que publicaste "más o menos" explica la razón, aunque no muy claramente: quieren que uses una alternativa mejor y no tienen la intención de arreglar o mejorar las ECE. Microsoft está colocando STE en el contenedor de "experimentos fallidos tempranos", similar a RDO o Remoting o LINQ2SQL. Presentan algo para ver qué tan bien funcionó y simplemente no funcionó.
En general, Microsoft siempre reconoció que las ECE eran una primera prueba para resolver un problema real de negocios, pero que estaban claramente incompletas. En particular, fueron muy malos para adjuntar gráficos de objetos con entidades compartidas, no admitían la carga perezosa y tenían una serie de otras limitaciones diversas.
Al parecer, MS ha decidido que no intentarán limpiarlos (observe que también desaprobaron la plantilla de POCO, por razones similares). Ya que no planean arreglar o mejorar la plantilla, quieren que la gente deje de usarla para nuevos proyectos y continúe con las mejores alternativas:
Generador DbContext
Esta plantilla generará clases de entidad POCO simples y un contexto que se deriva de DbContext. Esta es la plantilla recomendada a menos que tenga una razón para usar una de las otras plantillas que se enumeran a continuación.
Las STE existían principalmente para respaldar los casos en que las entidades estaban desconectadas y reconectadas a su contexto, especialmente en escenarios de serialización (WCF o servicios web, por ejemplo). En los objetos "estándar" de Entity Framework, todo el seguimiento de cambios se realizó en el contexto, y adjuntar una entidad existente a un contexto fue problemático. Las ECE hicieron ese proceso más fácil, pero a costa de hacer que casi todo lo demás sea realmente difícil.
Por lo que he visto y experimentado sobre el DbContext , se supone que es una mejor alternativa para resolver este problema, aunque en realidad no reproduce lo que hicieron las ESE. El consenso general entre los grandes usuarios de EF parece ser que la serialización de sus entidades EF de extremo a extremo es una idea realmente mala. En su lugar, deberías usar DTO y algo como AutoMapper para mapear entre tus objetos DTO y EF.
Mientras miraba el sitio web de Microsoft, descubrí que ya no recomiendan el uso de entidades de seguimiento automático.
Cada enlace a continuación es un recurso de MS que menciona no usar STE:
Muestra qué plantillas están disponibles por el equipo de Entity Framework: Plantillas de generación de código de EF Designer
¿Alguien sabe por qué Microsoft ya no recomienda usar STE?
Soy autor de Entidades rastreables como reemplazo de los STE: https://trackable.codeplex.com . Se implementa como un conjunto de paquetes NuGet y extensiones de Visual Studio. Hay un conjunto de plantillas de proyecto, con plantillas T4 para andamios de la API web de ASP.NET, así como plantillas de elementos para generar servicios WCF.
Aquí hay una publicación del blog que escribí comparando los TE con los STE: http://blog.tonysneed.com/2013/11/18/trackable-entities-versus-self-tracking-entities .
Saludos, Tony Sneed