Para una mejor comprensión, hemos dividido las características sobre las que vamos a hablar en dos grupos. Primero nos centraremos en las nuevas posibilidades asociadas a las herramientas de diseño incorporadas al entorno de desarrollo, para más adelante ocuparnos de las nuevas funcionalidades que nos ofrecerán las API que tendremos a nuestra disposición. El futuro de las herramientas de Entity Framework Una de las mejoras más potentes relacionadas con el diseñador visual que estará incluida en Visual Studio 2010 es la posibilidad de personalizar fácilmente el código generado a partir del CSDL (definición del modelo conceptual) a través de plantillas personalizadas, partiendo si queremos de una serie de plantillas predefinidas que estarán "de serie" a nuestra disposición. El generador de código por defecto de Entity Framework (en adelante EF) (EntityClassGenerator) es el encargado de crear, a partir del fichero CSDL (contenido dentro del fichero EDMX generado por Visual Studio), el código con las correspondientes clases .NET que representarán nuestras entidades y las asociaciones entre las mismas, clases que actualmente quedan incluidas dentro de un fichero .Designer.cs o .Designer.vb. En la práctica, muy frecuentemente nos vemos en la necesidad de modificar el código generado para adaptarlo a nuestras necesidades. Algunos ejemplos frecuentes son marcar entidades o propiedades con atributos personalizados, implementar determinadas interfaces propias, etc. La forma de personalizar el código generado en la primera versión de EF pasaba por utilizar el mecanismo de extensibilidad estándar del SingleFileGenerator, lo cual resulta bastante tedioso y problemático, especialmente a la hora de personalizar o depurar. En Visual Studio 2010 se abre la posibilidad de usar plantillas de T4 para personalizar la generación de código y que además la experiencia esté totalmente integrada con el diseñador de entidades. T4, o mejor dicho, el "Text Template Transformation Toolkit", es un motor de generación de código basado en plantillas. Está incluido con Visual Studio 2008 y Visual Studio 2010 (y es descargable para Visual Studio 2005 como parte de los toolkits de DSL y de GAT). Este motor puede usarse para generar código en C#, Visual Basic, T-SQL, XML o para generar cualquier fichero de texto como informes o páginas HTML. El mecanismo es sencillo: a partir de datos de entrada y la plantilla correspondiente (un archivo con extensión .tt conteniendo bloques de texto y lógica de control con una filosofía muy similar a ASP o cualquier lenguaje de macros), se genera el fichero o los ficheros resultantes. La forma de trabajar sería la siguiente. Seleccionamos el EDMX para el que queremos personalizar el código y añadimos al proyecto un nuevo elemento de Generación de Artefactos, concretamente el "ADO.NET EntityObject Generator". Esto hará que se elimine el código generado por defecto (.Designer.cs o .Designer.vb) y se abra la plantilla .tt predeterminada. El desarrollador podrá modificar este fichero para aplicar las personalizaciones que desee. Visual Studio se encargará entonces de generar el correspondiente fichero de código a partir de esta plantilla. En la figura 1 podemos ver un ejemplo de personalización de la plantilla, en el que hemos especificado que la clase de contexto implemente una interfaz IValidate. Esta capacidad permitirá que el equipo de EF pueda, por ejemplo, liberar nuevas plantillas T4 fuera de los ciclos de salida de Visual Studio y de .NET con nuevas capacidades o correcciones. Pero no solo eso: abrirá nuevas posibilidades hasta ahora no contempladas, como la posibilidad de crear plantillas que se integren con Visual Studio a través de la API EnvDTE para generar nuevos ficheros de proyecto o generar documentación HTML con las características de nuestro modelo conceptual. Podremos incluso empaquetar estas plantillas T4 en plantillas de elementos de proyecto de Visual Studio para que los usen los miembros de un equipo de desarrollo. Este mecanismo proporciona una vía fácil y potente de extensibilidad y personalización. La próxima versión de EF usa T4 no solo para la generación de código, sino también para hacer posible la utilización en nuestros desarrollos de una filosofía El modelo primero (Model First), sin duda una de las características más demandadas por la comunidad. En la primera versión de EF, es necesario partir del esquema relacional de una base de datos para poder definir y mapear un modelo conceptual. Al añadir un nuevo modelo de EF a nuestro proyecto, tenemos que especificar mediante un asistente la base de datos sobre la que queremos definir nuestro modelo conceptual. Se trata, por tanto, de un diseño El esquema primero (Schema First). En Visual Studio 2010 podremos definir inicialmente nuestro modelo conceptual, con las correspondientes entidades, sus jerarquías de herencia y sus relaciones, para luego lanzar desde el menú contextual del diseñador un asistente que o bien creará bien ficheros independientes con las sentencias DDL (Data Definition Language) con la sintaxis correspondiente al repositorio de datos elegido, o bien desplegará directamente el correspondiente esquema al servidor de base de datos elegido usando esas mismas sentencias DDL.
Por defecto, al generar las sentencias DDL se usa una solución Tabla-por-Tipo (TPT), es decir, se crea una tabla por cada tipo y subtipo. Por ejemplo, para el modelo de la figura 2, se generará el esquema que se muestra en la figura 3. Es de señalar que la generación de las sentencias DDL se implementa mediante un flujo de trabajo de Workflow Foundation expresado en XAML, por lo que puede sustituirse fácilmente por uno propio, total o parcialmente, por ejemplo, para hacer uso de un esquema Tabla-por-Jerarquía (TPH) en lugar de TPT. Este hecho, como muchas de las nuevas posibilidades en relación con la experiencia de diseño, viene a proporcionarnos una gran capacidad para meternos dentro de los entresijos de la tecnología para permitirnos modificarla y adaptarla a nuestras necesidades. Un paso más allá de la filosofía El modelo primero sería El código primero (Code First). Es decir, que partiendo de clases definidas en .NET podamos generar el correspondiente modelo conceptual de EF. El grupo de producto ha presentado un prototipo con esta capacidad y está estudiando diversas formas de implementarla, aunque por ahora no es posible asegurar que esta característica formará parte de la próxima versión de Visual Studio. Otra mejora reseñable dentro de las herramientas de diseño de EF para la próxima versión lo constituye el soporte para los tipos complejos. Es decir, con Visual Studio 2010 se podrán crear, editar y borrar tipos complejos en el navegador de modelos y usarlos en propiedades de entidades, o como tipo de retorno de procedimientos almacenados.
Por otro lado, el mapeo de importación de funciones permitirá especificar cómo se mapean los parámetros de retorno de los procedimientos almacenados a las correspondientes propiedades de las entidades o tipos complejos; en la primera versión, este mapeo era implícito y los nombres tenían que casar.
Para terminar con el conjunto de novedades dentro del apartado de herramientas, podemos destacar un excelente soporte para la búsqueda de información dentro de los modelos EDM, incluyendo el resaltado de los elementos visuales.

El futuro de EF Muchas son también las mejoras y nuevas capacidades que se incluirán en la próxima versión de las librerías que componen EF. Hemos resumido algunas de las más destacadas a continuación; podrá encontrar más información sobre ellas en la entrevista a Danny Simmons y Diego Vega, destacados miembros del equipo de EF, en este mismo ejemplar. Como sabréis, EF implementa un patrón de diseño denominado Carga perezosa (Lazy Loading). Esto significa que cuando realizamos una consulta sobre un conjunto de entidades, por defecto, los Servicios de objetos no se traen las entidades relacionadas (el grafo correspondiente) de la base de datos. La forma de especificar la expansión de la consulta, es decir, la inclusión de las entidades relacionadas en el conjunto de resultados, es mediante la utilización del método Include en la definición de la consulta, o bien mediante una llamada explícita a Load para lanzar la correspondiente consulta a la base de datos para obtener las entidades relacionadas. Por ejemplo, en el listado 1 especificamos a través de Include que deseamos obtener adicionalmente los productos correspondientes a las categorías seleccionadas por la consulta; por otro lado, en el listado 2 la carga de los productos la hacemos bajo demanda mediante una llamada a Load. Como puede ver, en ambos casos la carga de las entidades relacionadas tiene que ser explícita. Si quisiéramos abstraernos de esta necesidad y no cargar el código con llamadas a IsLoaded/Load para comprobar si las relaciones están cargadas y si no lo están hacerlo, podríamos implementar una carga perezosa transparente o implícita, similar a la que ofrece LINQ to SQL. Existen varias estrategias para hacerlo, y una buena forma de revisar las implicaciones y posibilidades de cada una de ellas es acudir al blog de Jaroslaw Kowalski [5]. Pues bien, en la próxima versión de EF podemos contar con ello, y mediante una opción del contexto de trabajo podremos especificar si queremos una carga perezosa implícita. Otra de las mejoras que incluirá la próxima versión será el soporte de objetos POCO (Plain Old CLR Objects). Es decir, las clases correspondientes a las entidades del modelo no tendrán por qué derivar de EntityObject, como ocurre actualmente, de forma que pueda usarse el mismo modelo conceptual de una forma independiente del Marco de trabajo usado en el mapeo relacional.
Con respecto al soporte del modelo N-capas, la próxima versión de EF ofrecerá varias vías para facilitar el desarrollo de este tipo de aplicaciones, incluyendo un modelo basado en la auto-gestión de los cambios por parte de las entidades (self-tracking entities), de forma que éstas, al serializarse, mantengan la información de estado, y podamos, por tanto, implementar fácilmente modelos de concurrencia optimista en el escenario desconectado. Por otro lado, para mejorar la experiencia de uso de LINQ to Entities, y poder usar en las consultas las funciones canónicas de Entity SQL (matemáticas, de cadenas, de fechas, etc.), se va a permitir la posibilidad de definir métodos que se mapeen a funciones definidas o declaradas en el nivel conceptual (EDM) o en el espacio de almacenamiento (SQL Server, etc.), de forma que a través de estos métodos podamos hacer uso de la función correspondiente dentro de una consulta de LINQ to Entities. Un ejemplo de esta posibilidad se refleja en el listado 3, donde inicialmente mapeamos la función canónica DiffYears, y luego la usamos dentro de una consulta.
Para finalizar, y no menos importante que el resto de novedades, los amantes de TDD (Test Driven Design) encontrarán un gran número de ventajas que les permitirán testear fácilmente las capas de persistencia creadas con EF, no solamente gracias a la aparición del soporte de POCO, sino por el hecho de que la mayoría de API están basadas en interfaces, y por lo tanto son fáciles de simular mediantes los distintos frameworks de mocking que tenemos a nuestra disposición.

Conclusiones Como hemos podido comprobar, el futuro de EF nos depara grandes novedades y mejoras, que harán la experiencia de trabajo con él mucho más productiva y flexible. La próxima versión nos permitirá adaptar mucho fácilmente el comportamiento del marco de trabajo a nuestras necesidades y aumentar en gran medida la productividad del desarrollo, al mismo tiempo que simplificará el mantenimiento de las soluciones basadas en el marco de entidades.