Self-Tracking Entities en Entity Framework 4

por emmanuel  24. agosto 2010

Introducción: tipos de entidades en Entity Framework

Desde la salida de Entity Framework, al generar modelos de entidades, las clases generadas derivan de EntityObject.
Con la salida de la versión 4 de Entity Framework, se incorpora soporte para seleccionar el tipo de entidad de la cual van a derivar nuestras entidades de negocio: a los clásicos EntityObject se agregan como novedad POCO, POCO Proxies y Self-Tracking entities.
Antes de desarrollar las entidades de tipo Self-Tracking (el objetivo de este artículo), es conveniente dar un panorama de estos diferentes tipos de entidades, para poder decidir cual utilizar, dependiendo de la arquitectura de la aplicación a realizar:

  • EntityObject

Por defecto, las herramientas de ADO.NET Entity Data Model generan tipos de entidades que derivan de EntityObject. En este caso, el ObjectContext administra las relaciones entre los objetos, mantiene el historial de los cambios que ocurren (Change-Tracking) y soporta Lazy Loading.

Sin embargo, este tipo de entidades dependen fuertemente del Entity Framework. Si se desea trabajar con arquitecturas que no conocen la forma de persistencia (por ejemplo: TDD, Test-Driven Development), lo más deseable es utilizar entidades de tipo POCO o POCO Proxy.

  • POCO

Entity Framework permite utilizar objetos del dominio existentes junto con el modelo de datos, sin hacer cambios a las clases de datos. Estas clases POCO ("Plain-Old" CLR Objects), son conocidas como objetos que ignoran la persistencia y soportan las mismas funcionalidades de Query, Insert, Update y Delete que los objetos EntityObject.

Al trabajar con entidades POCO, los cambios que se realicen al grafo de objetos no son mantenidos automáticamente por Entity Framework a medida que ocurren, sino que se utiliza un mecanismo de snapshots para detectarlos: se debe llamar a DetectChanges para sincronizar el ObjectContext con el grafo actualizado (por defecto, el ObjectContext llama a este método antes de grabar los datos).

Este mecanismo utiliza mas memoria que el anterior y puede afectar la performance, especialmente si la aplicación requiere la detección de cambios frecuentemente. Para poder tener una notificación instantánea de los cambios, se debe activar la creación de objetos Change-Tracking Proxy, y para activar Lazy Loading se debe activar la creación de Proxies de Lazy Loading.

  • POCO Proxy

Se debe utilizar en los casos en los que se requiera detección de cambios instantánea y Lazy Loading. Al utilizarlo, se tiene la misma funcionalidad que con entidades tipo EntityObject, pero con las clases del dominio separadas del Entity Framework. Los proxies se crean en tiempo de ejecución, lo que implica que las entidades generadas difieren del tipo POCO, introduciendo algunas complicaciones con la serialización. Por otra parte, la creación de proxies consume mas recursos que los objetos POCO.

  • Self-Tracking Entities

Los tres tipos definidos anteriormente funcionan correctamente en aplicaciones donde los objetos pueden ser agregados (Attach) al ObjectContext que maneja el historial de cambios. Sin embargo, cuando se desea transferir un grafo de entidades a una capa donde el ObjectContext no está disponible, se debe decidir como mantener el historial de cambios y reportar esos cambios de vuelta al ObjectContext (por ejemplo: arquitectura en capas, ambientes desconectados, arquitecturas SOA, etc.).

A partir de la versión 4 de Entity Framework, las entidades del tipo Self-Tracking pueden grabar cambios a las propiedades escalares, complejas o de navegación. Este tipo de entidades no dependen del Entity Framework, y son generadas con el template de ADO.NET Self-Tracking Entity Generator.

Self-Tracking Entities

En arquitecturas en capas, el ObjectContext puede no estar disponible en la capa que modifica las entidades. A partir de Visual Studio 2010 (con Entity Framework 4), está disponible el template ADO.NET Self-Tracking Entity Generator. Este template genera dos archivos .tt (text template):

El archivo <nombreModelo>.tt genera los tipos de entidades y una clase helper que contiene la lógica de mantenimiento de cambios, mas los métodos de extensión que permiten establecer el estado de las entidades.

El archivo <nombreModelo>.Context.tt genera un ObjectContext tipado y una clase de extensión que contiene los métodos ApplyChanges para las clases ObjectContext y ObjectSet. Estos métodos examinan la información del historial de cambios para inferir las operaciones a realizar para grabar los cambios en la base de datos.

Para acceder al template se debe hacer click derecho sobre la superficie del diseñador de entidades, y seleccionar “Add Code Generation Item”:

SelfTracking001

 

En la ventana que aparece, seleccionar “ADO.NET Self-Tracking Entity Generator”:

SelfTracking002

Al presionar “Add”, se ejecutarán los templates que crearán las clases necesarias, las cuales contendrán los métodos de extensión necesarios para trabajar con Self-Tracking:

SelfTracking003

Métodos de extensión de Self-Tracking Entities

  • StartTracking

Este método se utiliza para comenzar el Change-Tracking (rastrear cualquier cambio que ocurra en la entidad). Esto incluye propiedades escalares, colecciones y referencias a otras entidades. Las entidades de tipo Self-Tracking inician el Change-Tracking automáticamente cuando son deserializadas en un cliente a través de WCF. También se activa para nuevas entidades creadas en los siguientes escenarios:

  1. Una relación es creada entre la nueva entidad y una entidad que actualmente tiene Change-Tracking activado.
  2. Se llama al método MarkAs o AcceptChanges en una entidad.

 

  • StopTracking

Este método finaliza el Change-Tracking en una entidad.

  • MarkAs

Todos los métodos que comienzan con “MarkAs” activan el Change-Tracking. Estos métodos permiten cambiar el estado de una entidad a Added, Modified, Deleted, o Unchanged, y además retornan la misma entidad a la cual son aplicados, con el estado modificado:

MarkAsAdded cambia el estado de una entidad a Added. Las nuevas entidades Self-Tracking son creadas en este estado y con Change-Tracking desactivado.

MarkAsDeleted cambia el estado de una entidad a Deleted.

MarkAsModified cambia el estado de una entidad a Modified. Este estado también se obtiene al cambiar el valor de una propiedad en una entidad con Change-Tracking activado.

MarkAsUnchanged cambia el estado de una entidad a Unchanged. También se obtiene este estado al llamar al método AcceptChanges.

  • AcceptChanges

Este método elimina la información de Change-Tracking para una entidad y coloca el estado en Unchanged (es decir, la entidad acepta los cambios que se le realizaron).

Métodos de extensión de ObjectContext

  • ApplyChanges

Examina la información del historial de cambios contenida en el grafo de entidades e infiere el conjunto de operaciones que deben realizarse para reflejar los cambios en la base de datos. Hay dos métodos ApplyChanges, uno para el ObjectContext y otro para el ObjectSet.

Consideraciones para trabajar con entidades Self-Tracking

Finalmente, para cerrar, les dejo algunas consideraciones a tener muy en cuenta antes de utilizar este tipo de entidades:

  • Al enviar un grafo modificado a un servicio, y luego intentar continuar trabajando con el el grafo modificado en el cliente, se debe iterar manualmente por el grafo en el cliente y llamar a AcceptChanges en cada objeto para resetear el Change-Tracking.

  • Las entidades Self-Tracking no permiten realizar Lazy Loading.

  • La serialización Binaria y la serialización a objetos de administración de estados ASP.NET no es soportada por el código generado por los templates de ADO.NET Self-Tracking Entity Generator, para soportala se debe agregar el código necesario al template.

Fuentes:

Tags: ,

ADO.NET | Entity Framework | Visual Studio

Migración a Team Foundation Server 2010 – Donde están los Reportes?

por Daniel Laco  20. agosto 2010

 

Dónde quedan los reportes de TFS2008 cuando se realiza la migración a TFS 2010?

A no preocuparse si acceden a los viejos reportes y ven que la fecha de actualización del cubo quedó congelada a la fecha de la migración, porque los reportes están ahora en una nueva locación

Por los cambios producidos en los modelos en la nueva version 2010, el proceso de actualización que realiza TFS hace que se instalen las nuevas bases de datos y cubos siguiendo el concepto de Project Collections (ver http://www.vemn.com.ar/Blog/post/Nuevos-conceptos-en-TFS-2010.aspx)

Las bases anteriores TFSWarehouse y al cubo también llamado de la misma manera siguen existiendo y los reportes en Reporting Services (SSRS) siguen apuntando a esta base .

Pero los reportes para los templates basados en MSF for Agile y MSF for CMMI en la versión 4.2 son migrados a un nuevo directorio en Reporting Services. Este directorio se llama TFSReports y dentro de él está el directorio DefaultCollections (esto dependiendo del nombre de la collection que fué creada en la migración). Dentro de este último directorio vamos a encontrar todos los reportes de los proyectos anteriores migrados a la nueva versión 2010 de TFS.

Por supuesto, que todos los proyectos abiertos desde Visual Studio, apuntan ahora a la nueva ubicación. Esta ubicación es sacada desde la consola de configuración de TFS.

En el gráfico siguiente, está un esquema de como quedan ahora las bases de datos y los Data Sources de Reporting Services

 

ServerUpgrade

 

Tambien tenemos nuevos Data Sources

2008

2010

TfsReportsDS

Tfs2010ReportsDS

TfsOlapReportsDS

Tfs2010OlapReportsDS

 

Aquí les dejo una serie de link sobre información puntual sobre el tema de reportes (algunos extraidos del blog de Buck Hodges:

Sunder Raman, Program Manager para TFS, ha escrito una serie de post (en inglés) sobre los cambios en el almacenamiento y en los cubos para 2010.

Reporting

 

Customizing Reports for Team Foundation Server 2010 (en MSDN)

Cube

 

 

John Socha-Leialoha, escribió una serie de post sobre la actualización de reportes en TFS

Tags: , ,

ALM | Gestión de Proyectos | TFS

Migración de TFS 2010 - Como detener o iniciar todos los servicios?

por Daniel Laco  19. agosto 2010

 

Si es necesario hacer backup o restore de las bases de datos, o mover una instalación o hacer cambios importantes, es útil contar un algo que nos permita con un solo comando parar o arrancar todos los servicios que usa Team Foundation Server.

Hay una herramienta de linea de comandos  que se llama TFSServiceControl que permite realizar esas operaciones con todos los servicios,  y los Application Pools que usa el Team Foundation Server.

El comando se usa:

TFSServiceControl [quiesce|unquiesce]

TFSServiceControl quiesce Detiene los servicios

TFSServiceControl unquiesce Inicia los servicios

 

Fuente (en inglés) : http://msdn.microsoft.com/en-us/library/ff470382.aspx

 

Tags: ,

ALM | Gestión de Proyectos | TFS

Nuevos conceptos en TFS 2010 – Categorizando Work Items

por Victor Passador  10. agosto 2010

Siguiendo con nuestra idea de mostrar novedades que exceden la calificación de “nueva característica”, y que nos ponen en situación de repensar algunas situaciones, quisiera comentar sobre las Categorías de Work Items.

Ahora, con TFS 2010, podemos categorizar Work Items, pero … ¿por qué querríamos o necesitaríamos hacer esto?.

Porque tendríamos la posibilidad de tratar de la misma manera a aquellos work items que son diferentes pero parecidos, teniendo en cuenta que cuando hablo de “tratar” estoy apuntando al seguimiento de esos work items. Con este nuevo agrupamiento podríamos por ejemplo:

  • Construir queries, con una sintaxis mucho más simple e intuitiva, que devuelvan work items de más de un tipo. ¿O acaso una “User Story” y un “Quality of Service Requirement” no son en definitiva requerimientos del usuario?
  • Construir reportes de manera más simple apuntando a obtener resultados más “macro” sin resignarnos a perder el detalle de lo que hay debajo (… o ver el bosque y también ver los árboles). Cada work item tendrá su propia estructura de datos, con el nivel de detalle que requiera cada uno, pero aquella información que tengan en común podría ser explotada en reportes utilizando estas nuevas categorías.
  • Construir Test Suites utilizando Microsoft Test Manager (el nuevo integrante de la familia TFS, del que estaremos posteando/presentando novedades muy pronto)

 

Para crear queries que respondan a este nuevo agrupamiento, tenemos disponible el comando “In Group”. Aquí tienen un ejemplo de una query utilizada por el Microsoft Test Manager que se vale de este nuevo operador.

image

Estas categorías están definidas en el template con el cual fue creado el proyecto. Es por este motivo que no encontraremos (al menos por ahora) ningún botón que diga “Add New Category”.

Pero no todo está perdido, si nos damos un poco de maña, nos prometen que podemos categorizar work items en proyectos que no tenían esa facilidad.

Hasta la próxima !

Tags: , ,

ALM | Gestión de Proyectos | TFS

Permisos para Reportes Excel en TFS 2010

por Daniel Laco  4. agosto 2010

Aqui les dejo una vista rápida sobre los permisos necesarios para ejecutar reportes de Excel en TFS 2010. (info detallada en: http://msdn.microsoft.com/en-us/library/bb649553.aspx)

Permisos para acceder a Excel Reports que se conectan a la base de datos operacional

Activity

Team Foundation Server

Team project portal (SharePoint)

Notes

View or refresh an Excel report that is opened from the Documents node of Team Explorer

Readers

Visitors

To access the Documents node for a team project, you must belong to theTeam Foundation Valid Users security group. If the required security permissions are set explicitly, your View project-level information permission on the team project must be set to Allow.

Run a work-item query, and use the Open in Microsoft Excel feature

Readers

In addition, you may require permission to open a team query. For more information, see Organize and Set Permissions on Work Item Queries.

Create a Microsoft Excel report

Readers

 

To modify work items from Microsoft Excel, you must belong to theContributors group, or your Edit work items in this node permissions must be set to Allow.

Manage Excel reports in the Documents node

Readers

Members

To view the Documents node, you must have access to the team project. To manage files under the Documents node, you must be a contributing member for the SharePoint site. For more information, see Managing Documents and Document Libraries.

Permissions for Excel Reports That Connect to the Analysis Services Cube

Activity

Team Foundation Server

Team project portal

Analysis Services cube (Tfs_Analysis)

Notes

Open the Documents node in Team Explorer, and view or refresh a Microsoft Excel report

Readers

Visitors

TfsWarehouse DataReader role

To access the Documents node for a team project, you must belong to the Team Foundation Valid Userssecurity group. If the necessary security permissions are set explicitly, your View project-level information permission on the team project must be set to Allow.

View or refresh a Microsoft Excel report that appears in an enterprise dashboard

  

Visitors

In addition to Visitors or Read permissions, you must belong to a group that is granted access to theTfsWarehouseDataReader role or the Single Sign-on enterprise application definition for the SharePoint web application.

For more information, see Excel Reports (Agile) orExcel Reports (CMMI).

Run a work item query, and then use Create Report in Microsoft Excel

Readers

TfsWarehouse DataReader role

In addition to these permissions, you may require permission to open a team query. For more information, see Organize and Set Permissions on Work Item Queries.

Use the New Excel Reportfeature from a dashboard

Visitors

TfsWarehouse DataReader role

The New Excel Report button is available only if reporting is configured for the project collection that hosts the team project.

Create a report from Microsoft Excel that connects to the Analysis Services cube

TfsWarehouse DataReader role

If you want to save the resulting workbook to the project portal, you must belong to the Members group for SharePoint Products.

Manage Microsoft Excel reports in the Documents node

Readers

Members

  

You must be a contributing member of the SharePoint site to save files under the Documents node. For more information, see Managing Documents and Document Libraries.

 

Permissions for Reporting Services Reports

Activity

Reporting Services

Analysis Services cube (Tfs_Analysis)

Relational data warehouse (Tfs_Warehouse)

View or refresh a report 

Browser

Create a report that accesses data from the Analysis Services cube

Browser

TfsWarehouseDataReader role

Create a report that accesses data from the relational data warehouse

Browser

TfsWarehouseDataReader role

Manage reports

Team Foundation Content Managers group

Tags:

ALM | Gestión de Proyectos | Metodologías y Procesos | TFS

Acerca de los Autores

Este es el blog del equipo de VEMN SA 
Presentaremos temas que nos parezcan de interés sobre tecnología .NET, Procesos y Metodologías y todo aquello relacionado con el proceso de desarrollo de Software

Month List

BlogRoll

Download OPML file OPML