Una de las nuevas características que se han desarrollado en Entity Framework 4.0, es la posibilidad de usar entidades Selft-Tracking. Las entidades Self-Tracking son clases que no tienen dependencia de Entity Framework, pero que incluyen mecanismos que gestionan los cambios es sus propiedades.
Estas entidades nos permiten enviarlas a un cliente (por medio de WCF, por ejemplo), realizar cambios sobre ellas y recibirlas conociendo que cambios se han realizado, sin necesidad de consultar el contexto. Con estos cambios y con algunas nuevas funcionalidades de Entity Framework 4 se obtiene un mejor rendimiento cuando persistimos las entidades en el contexto.
Cada clase de nuestro modelo implementa la interfaz IObjectWithChangeTracker, que tiene los métodos necesarios para gestionar los cambios (Unchanged, Modified, Added o Deleted), y no sólo gestiona los cambios, sino que también mantiene los valores originales.
Para generar las entidades Selft-Tracking nos tenemos que instalar la CTP2 de Entity Framework, que la podemos descargar aquí.
Una vez instalada la CTP2, tendremos una nueva opción en nuestro modelo (fichero edmx) que nos permite añadir un nuevo elemento de generación de código.
y en la ventana de nuevo elemento, tenemos la opción del generador de entidades Selft-Tracking de ADO.NET (ADO.NET Selft-Tracking Entity Generator)
¿Qué hemos conseguido con esto? Bueno, si revisamos nuestro Solution Explorer, podemos observar que se han creado dos nuevos elementos, ClientesModel.Context.tt y ClientesModel.Types.tt.
Estos dos nuevos ficheros son plantillas de texto T4 que se utilizan para generar código. Estas plantillas generan las clases necesarias para Selft-Tracking, tanto para el Contexto como para nuestras entidades del modelo. Más información sobre plantillas T4 en el siguiente post.
Ahora tenemos generados el código necesario para nuestro Selft-Tracking Context y para nuestras Entidades Self-Traking, pero ¿es recomendable dejar nuestras entidades en el mismo proyecto que nuestro contexto? Si lo que queremos es desarrollar una aplicación N-tier, la respuesta es no, lo ideal, para poder reutilizarlo en todas nuestras capas, sin dependencias de Entity Framework, sería separar la plantilla ClientesModel.Types.tt en otro proyecto para que pueda ser utilizado en cualquier capa de nuestra aplicación.
Veamos cómo debería de quedar.
Al separar nuestras entidades (ClientesModel.Types.tt), tendremos que hacer ciertos cambios en estas plantillas para que la generación y las referencias sean las correctas.
-
Añadimos en el proyecto Data la referencia al proyecto Model.
-
Las entidades Self-Tracking se generan con la capacidad de que puedan ser serializadas, necesitaremos añadir la referencia a System.Runtime.Serialization al proyecto Model.
-
Modificamos la plantilla ClientesModel.Types.tt para que genere nuestro modelo a partir del fichero edmx. Cambia la ruta de la variable string inputFile = @»ClientesModel.edmx» a @”..EfTracking.DataClientesModel.edmx”.
-
Por último, modificamos la plantilla ClientesModel.Context.tt para que incluya los using necesarios para que utilice nuestras entidades que están en el namespace EfTracking.Model. Buscamos las dos secciones de using que se encuentran en la plantilla y añadimos la nuestra.
Con estos cambios, conseguimos distribuir nuestras entidades, incluyendo la plantilla de generación del código, en otro proyecto (dll) para su reutilización en cualquiera de las capas (cliente, servicio, datos, etc.). Al incluir la plantilla, mantenemos su funcionalidad que nos permitiría modificar nuestro Entity Framework (fichero edmx) y que se reflejen los cambios en las entidades Self-Tracking.
Si nos creamos un servicio que utilice las entidades y el contexto, con Self-Tracking podemos obtener nuestra entidad y realizar la actualización de la misma, utilizando el siguiente método:
1: public Model.Contact UpdateContact(Model.Contact contact)
2: {
3: using (var context = new Data.ClientesEntities())
4: {
5: context.Contacts.ApplyChanges(contact);
6: context.SaveChanges();
7:
8: return contact;
9: }
10: }
El método ApplyChanges es una nueva funcionalidad que permite enlazar las entidades e interpretar los cambios realizados para persistirlos a nuestro contexto.
Tenemos que tener en cuenta que implementando la funcionalidad de Self-Tracking en nuestra aplicación, limitamos la interoperabilidad de nuestra aplicación ya que no podemos asegurar que la funcionalidad de Self-Tracking sea manejada por clientes no .NET.
Sin embargo, siempre hay que valorar si necesitamos esta nueva funcionalidad frente a poder interactuar con otros sistemas que no la pueden implementar.
Saludos a todos…