c# .net entity-framework self-tracking-entities

c# - ¿Cuál es el propósito de las entidades de seguimiento automático?



.net entity-framework (2)

El objetivo principal es ayudar en el desarrollo de N-tier. Dado que son de seguimiento automático, puede serializarlos en, por ejemplo, un servicio WCF, luego deserializarlos, y aún sabrán qué cambios se han realizado y están pendientes para la base de datos.

Las entidades de auto-seguimiento saben cómo hacer su propio seguimiento de cambios sin importar en qué nivel se realicen dichos cambios. Como arquitectura, las entidades de seguimiento automático se encuentran entre los DTO y los DataSets e incluyen algunos de los beneficios de cada uno.

http://blogs.msdn.com/b/efdesign/archive/2009/03/24/self-tracking-entities-in-the-entity-framework.aspx

He estado leyendo sobre entidades de seguimiento automático en .net y cómo se pueden generar a partir de un archivo * .edmx. Lo que estoy luchando por comprender es ¿qué generar estas entidades te da sobre las entidades EF básicas? Además, algunas personas han mencionado las entidades de auto-seguimiento y Silverlight, pero ¿por qué usarías estas en lugar del cliente o las clases compartidas generadas por los servicios de RIA?

¿Cuál es el sentido de las entidades de seguimiento automático y por qué las usarías?


Las entidades de seguimiento automático (STE) son la implementación del conjunto de cambios (la implementación anterior de .NET del conjunto de cambios es DataSet ). La diferencia entre STE y otros tipos de entidades (POCO, EntityObject) es que los tipos de entidades comunes pueden rastrear los cambios solo cuando están conectados a ObjectContext vivo. Una vez que la entidad común se separa, pierde cualquier capacidad de seguimiento de cambios. Esto es exactamente lo que STE resuelve. STE puede realizar un seguimiento de los cambios incluso si los separa de ObjectContext .

El uso común de STE se encuentra en escenarios desconectados, como comunicación de .NET a .NET a través de servicios web. La primera solicitud al servicio web creará y devolverá STE (la entidad se desconectará cuando se serialice y ObjectContext solo viva para servir una sola llamada). El cliente hará cambios en STE y lo devolverá en otra llamada de servicio web. El servicio podrá procesar los cambios porque tendrá disponible el seguimiento de cambios internos de STE.

Es posible manejar este escenario sin seguimiento de cambios, pero es mucho más complejo, especialmente cuando se trabaja con un gráfico de objetos completos en lugar de una sola entidad: se deben fusionar manualmente los cambios recibidos del cliente con el estado actual en la base de datos.

Tenga en cuenta que las STE no son para soluciones interoperables porque su funcionalidad se basa en compartir el código STE entre el servidor y el cliente.