Entity Framework: Como solucionar los problemas en la carga de la metadata!

Hacía tiempo que no “jugaba” con las últimas versiones de Entity Framework y esta tarde mientras estaba usando un control de tipo EntityDataSource me encontré conque al intentar usar el EDM de EF que tenía definido en el proyecto de Visual Studio el asistente de configuración de la fuente de datos subyacente me soltaba un error la mar de majo: “The metadata specified in the connection string could not be loaded. Consider rebuilding the web project to build assemblies that may contain metadata. The following error(s) ocurred: Unable to load the specified metadata resource”. Lógicamente, tras decir WTF me puse a tratar de solucionar el asunto porque necesitaba poder configurar ese EntityDataSource para una pequeña prueba de concepto…

image

Tras revisar que las cadenas de conexión estaban correctas en el Web.Config y que el problema no se debía al modelo de EF generado en Visual Studio 2013, me puse a bucear por la red en busca de este error y similares, y por suerte (y también por desgracia), me encontré con varias entradas reportando el problema para versiones anteriores a la 6.0 de EF…tras varias pruebas sin resultados, finalmente encontré un par de referencias que me llevaron a la solución al problema

En particular, el segundo enlace es el que contiene la descripción del problema y la solución dada por Diego de La Vega de Microsoft:

Certainly, the EntityDataSource that is part of .NET framework does not support EF6. When you get the error it is because the control is trying to load the model in the EF5 runtime, which does not support 2012 as the value for ProviderManifestToken.We have an updated version of the EntityDataSource in the works that supports the EF6 runtime, and the current plan is to make it available in a NuGet package.

  • In the meanwhile, it seems that there are two workarounds: – Editing your edmx file and replacing 2012 with 2008 then using EF5 instead of EF6
  • Using model binding for WebForms instead of a DataSource control.

Tras esto, me puse manos a la obra para probar si alguno de los dos workaround funcionaba empezando por el primero:

  • En Visual Studio 2013, edité el archivo .edmx de mi modelo y efectivamente, aparece la propiedad ProverManifestToken con el valor 2012.

image

  • Tras cambiar el valor de ese atributo de 2012 a 2008 y recompilar el proyecto, ya pude configurar sin problemas el control EntityDataSource y usarlo en mi POC…por lo que con el primer workaround, se soluciona el problema.

image

De acuerdo al mismo mensaje de Diego de La Vega, se estaba trabajando en una nueva versión de EntityDataSource que solucione este problema…desconozco si la nueva versión está disponible o no.

ADO.NET EF: Aplicaciones de ejemplo de las que partir!

Sin duda, cuando se está iniciando la inmersión en una tecnología en la que no se tiene experiencia es muy recomendable disponer de una serie de ejemplos iniciales de los que partir que faciliten su aprendizaje. En este sentido, y para el caso de ADO.NET Entity Framework, en MSDN disponemos de varias aplicaciones de ejemplo que permiten evaluar las posibilidades que brinda esta tecnología para el acceso a datos. Los ejemplos disponibles son los siguientes:

Podremos descargar estos ejemplos desde el siguiente enlace: Entity Framework Documentation Samples

ADO.NET EF: Trabajo con BD’s grandes!

Otra pregunta que suele aparecer a la hora de elegir Entity Framework para la creación de aplicaciones empresariales basadas en BDs grandes es como de fácil puede resultar trabajar con este tipo de BD’s en los Entity Data Models (EDMs) que generemos a partir del esquema de BD subyacente. Aunque no hay mucha información al respecto, os dejo una pequeña recopilación de recursos en torno a este tema:

Una pregunta que se nos puede venir a la cabeza es: ¿Cuál es el umbral para comenzar a pensar en dividir el EDM? La respuesta es que es recomendable dividir el modelo cuando tenemos un modelo con un número de entidades que supera la banda de las 50-100 entidades.

ADO.NET EF: + recursos y trabajo con plantillas T4!

Una de las novedades que vienen con la versión 4.0 de ADO.NET Entity Framework es el soporte para trabajar con plantillas T4. Indagando sobre T4, me he dado cuenta de que esta característica tan potente no es nueva de Visual Studio 2010, sino que ya está disponible en versiones anteriores (en concreto en VS 2005 y VS 2008). Os dejo algunos enlaces de interés respecto a EF 4.0, las posibilidades del uso de T4 en la construcción de aplicaciones software y por supuesto su relación con EF.

ADO.NET Entity Framework: Recursos para empezar a meterse en harina!

Aprovechando que estos días a uno de nuestros chicos (Mario, que en breve comenzará escribir en el blog :P) tiene que realizar una inmersión en ADO.NET Entity Framework, y ante la cantidad de recursos que hay disponibles en torno a la tecnología, he hecho un pequeño recopilatorio para hacer una aproximación inicial:

Y hasta aquí llega este recopilatorio sobre ADO.NET EF.

ADO.NET Entity Framework vs NHibernate: Una primera comparativa!

Sin duda, y aunque ADO.NET Entity Framework es la tecnología de presente y futuro para acceso a datos de manera agnóstica a la BD subyacente, hay que pensar que ahora mismo otras tecnologías como NHibernate le sacan cierta ventaja porque llevan más años en el mercado, son tecnologías más probadas y evolucionadas…pero, ¿qué pasa con el rendimiento? Sería interesante saber quien gana en términos de rendimiento en el acceso a datos. El caso es que alguien (Gergely Orosz) ya se ha preocupado de realizar una primera comparación en términos de rendimiento entre Entity Framework y NHibernate…y los resultados los podéis ver en este enlace. Y lo mejor para empezar a sacar conclusiones es analizar la tabla comparativa que ha realiza Gergely.

Operation \ Number of operations

NHiberante – 4K

Entity Framework – 4K

NHiberante – 40K

Entity Framework- 40K

Winner

Store

37,37

9,19

1500

98

Entity Framework

Read over relations

1,01

0,54

10,13

4,18

Entity Framework

Read by ID

3,06

25,22

246

230

NHibernate with smaller amount of objects

Update

6,61

7,34

77

72

Both

Delete

3,35

16,76

58

1824

NHibernate

VS 2010 & .NET Fx 4.0: Model First en ADO.NET Entity Framework 4.0!

Estos días estoy teniendo la oportunidad de “enredar” un poco con la nueva versión de ADO.NET Entity Framework (ADO.NET EF) que vendrá como parte de VS 2010 y .NET Fx 4.0. Entre las novedades de EF 4.0, tenemos la característica “Model First”, es decir, vamos a poder crear primero el Entity Data Model (EDM) y posteriormente generaremos la base de datos (BD) subyacente. Frente a esta característica, la versión 1.0 de EF sólo nos permitía construir un EDM a partir de una BD:

image image

La idea de este post es ver un pequeño paso a paso de como generar en primer lugar el EDM de EF y posteriormente la BD subyacente. Veremos además que la generación de esta BD se puede automatizar gracias a que se crea un workflow de WF 4.0 para ello. Empecemos.

Construyendo el modelo

Lo primero que vamos a hacer es construir el EDM de ADO.NET EF partiendo de la plantilla de modelo en blanco que tenemos disponible en Visual Studio:

  • Añadimos un nuevo elemento a nuestro proyecto de tipo ADO.NET Entity Data Model.
  • En el asistente de creación del modelo, elegimos Empty Model y pulsamos Finish.
  • Lógicamente, el modelo está vacío. Para ir añadiendo entidades al modelo, hacemos clic con el botón derecho del ratón sobre la superficie de diseño y pulsamos Add –> Entity …
image image image

  • En mi caso, voy a añadir dos entidades simples al modelo, que además estén relacionadas (mediante una relacuón 1:N). Básicamente, para cada entidad definiremos en primer lugar el nombre de la misma, su campo clave y el tipo correspondiente. A continuación le añadiremos las propiedades que estimemos oportunas. Para ello, seleccionamos la entidad, hacemos clic con el botón derecho del ratón y pulsamos Add –> Scalar Property. Utilizaremos la ventana de propiedades para su correcta configuración.-

    image image image

  • Para añadir una asociación entre las entidades, seleccionamos una de las entidad origen, hacemos clic con el botón derecho del ratón y pulsamos Add –> Association.
  • En la ventana que se abre, simplemente configuramos como queremos que sea la asociación y pulsamos Ok.
  • De esta forma, ya tendremos definida la asociación entre las dos entidades del modelo.
image image image

Generación de la BD a partir del modelo

Una vez que hemos construido el EDM de ADO.NET EF, ya estamos listos para generar la BD subyacente. Para ello:

  • Hacemos clic con el botón derecho del ratón sobre la superficie de diseño y pulsamos Generate Database Script from Model…
  • En la ventana que se abre, tendremos que especificar los parámetros de conexión pertinentes a través del botón New Connection…
  • Lógicamente, especificamos el nombre del servidor de BD y el nombre de la BD.
image image image

  • Tras especificar los parámetros de conexión, pulsamos Next.
  • En la siguiente pantalla veremos el conjunto de sentencias SQL que se construyen a partir del EDM para generar la BD subyacente.
  • Tras pulsar Finish, se generará el correspondiente archivo SQL en la solución de Visual Studio con todas las sentencias T-SQL necesarias.
image image image

  • Si nos vamos al SQL Server Management Studio, veremos que la BD se ha creado, pero está vacía por lo que tendremos que ejecutar el script anterior.
  • Otra característica interesante de esta nueva capacidad de ADO.NET EF 4.0 es que además de generar el script T-SQL con la definición de la BD, se crea un workflow de WF 4.0 pensado para automatizar este proceso de creación de la BD.
  • Este workflow aparece en la propiedad Generate Database Script Workflow del EDM. Si buscáis este workflow, lo encontraréis en la ruta siguiente: C:\Program Files\Microsoft Visual Studio 10.0\Extensions\Microsoft\EntityFrameworkTools\Workflows\DbGen.xaml. Como veis, se trata de n workflow secuencial sencillo que usa dos actividades personalizadas.
image image

Y hasta aquí llega lo que os quería contar sobre Model First en ADO.NET EF 4.0. Espero que el post os haya resultado interesante.

ADO.NET EF: Disponible Entity Framework Feature CTP1!

El equipo de ADO.NET Entity Framework (ADO.NET EF) acaba de anunciar la disponibilidad de la CTP 1 del Entity Framework Feature CTP1. Se trata de un paquete de funcionalidades para .NET Framework 4.0 Beta 1 que nos permitirá probar alguna de las novedades que trae la nueva versión de ADO.NET EF:

  • Mejor soporte para N-Capas con Self Tracking Entities.
  • Generación de entidades POCO (Plain Old CLR Objects) a través del POCO Template.
  • Escritura de código y ponerlo en funcionamiento con ADO.NET EF mediante Code Only.

SSRS 2008: Construyendo un informe a partir de un EDM de ADO.NET Entity Framework!

Siempre me digo que responder de forma tajante una pregunta que te hacen en torno a tecnologías es la opción cuando estás seguro de la respuesta, pero cuando no lo estás al 100 % lo mejor es responder que no sabes la respuesta. Precisamente esto es lo que me ha pasado en el último curso sobre SQL Server Reporting Services 2008 (SSRS 2008) que he impartido. La pregunta en este caso fue la siguiente: ¿Se pude crear un informe a partir de un Entity Data Model (EDM) de ADO.NET Entity Framework? Tras no pensarlo mucho, contesté que en el Report Designer de Visual Studio o en el Report Builder no porque espera una fuente relacional, un modelo de datos, datos XML, pero no un modelo de entidades de negocio como el que tenemos con EF o LINQ To SQL…la pregunta tenía toda su lógica ya que cuando diseñamos un informe en SSRS 2008 partimos de un dataset. El caso es que en este caso he de decir que la respuesta que di es cierta a medias puesto que si existe una forma de generar informes a partir de un EDM de EF o un modelo de LINQ To SQL o incluso llamando a un servicio de ADO.NET Data Services…la respuesta está en el control Report Viewer que tenemos en Visual Studio y que admite tanto informes locales como de servidor. Pero vamos al grano:

  • Lo primero es lógicamente crear un EDM de EF utilizando para ello el asistente que tenemos en Visual Studio 2008 SP1.
image image image
  • Una vez creado el EDM, compilamos el proyecto.
  • Añadimos un elemento al proyecto de tipo Reporting –> Report al proyecto…y es aquí dónde está la clave: puedo diseñar informes en modo local para ser consumidos por el control report viewer.
image image image
  • Se abre la superficie de diseño de SSRS (cuidado, que no es la de SSRS 2008 :-(, es nuestro viejo SSRS 2005…lo que no deja de ser curioso, pues estoy trabajando con un proyecto de .NET Framework 3.5 y tengo instalada toda la infraestructura de SSRS 2008). A través de la ventana Data Sources podemos especificar la fuente de datos para el informe haciendo clic sobre Add New Data Source…
  • En la ventana que sea abre elegimos una fuente de tipo Object…Ajá, aquí lo tenemos, en el momento en el que yo puedo especificar una fuente de datos tipo Object, ya hablo la posibilidad de crear informes a partir de mi EDM, de un modelo de LINQ To SQL o incluso a partir de un servicio de ADO.NET Data Services.
  • Esto nos permite elegir que objetos de negocio del proyecto actual queremos utilizar para crear el informe. Elegimos nuestro modelo de EF.
image image image
  • De esta forma, ya tenemos las entidades de nuestro modelo de EF listas para empezar a construir nuestro informe.
  • Añadimos una región de datos de SSRS a la superficie de diseño (en mi caso una tabla).
  • No tenemos más que arrastrar campos de las entidades de negocio a las zonas de datos del informe. En mi caso, he añadido dos campos de una de las entidades por simplicidad.
  • Guardamos el informe y añadimos un control de tipo Report Viewer a nuestro formulario Windows Form o Web.
image image image

  • Lo siguiente que tenemos que hacer es configurar el control Report Viewer vía código para que por una parte utilice el informe que hemos diseñado y por otra vincule de forma adecuada las entidades del modelo de EF con dicho informe.

            AdventureWorksEntities ctx =

                new AdventureWorksEntities();

            var dataSource = ctx.Product; 

            this.reportViewer1.ProcessingMode=

                Microsoft.Reporting.WinForms.ProcessingMode.Local;

            this.reportViewer1.LocalReport.ReportPath=

                System.Environment.CurrentDirectory +

                 @"\Product.rdlc";

            this.reportViewer1.LocalReport.DataSources.Clear();

            this.reportViewer1.LocalReport.DataSources.Add(

                new Microsoft.Reporting.WinForms.ReportDataSource(

                    "SSRS_LINQ_Product", dataSource));

            this.reportViewer1.RefreshReport();

  • Fijaros que para poder utilizar entidades del modelo de EF, lo único que hago es crear una instancia del objeto contexto de datos. Definir mi fuente de datos en base a una de las entidades del modelo, y a continuación configurar de forma adecuada el control reportviewer:
    • Fijamos el modo de procesamiento a local.
    • Especificamos el informe que vamos a visualizar en el control (el que hemos diseñado anteriormente).
    • Añadimos la fuente de datos al report viewer y lo reflescamos.
  • Tras compilar la aplicación, no tenemos más que probar que funciona…cool!!
  image  

Y hasta aquí llega este post…lo bien que se queda uno cuando encuentra la respuesta que contradice la afirmación realizada inicialmente. Espero que el post os haya resultado de utilidad.

ADO.NET Entity Framework…listado de proveedores de terceros!

Como sabéis, durante los últimos meses se ha producido un goteo continuo de nuevos proveedores de terceros con soporte de terceros para ADO.NET Entity Framework. Por este motivo, Microsoft ha habilitado una lista de estos proveedores para facilitar su localización:

image image

En cuanto al listado de proveedores, veréis que a día de hoy tenemos los siguientes con soporte para ADO.NET EF:

Devart, que ofrece soporte para ADO.NET EF para BD’s Oracle, MySQl y PostgreSQL.

 

Phoenix Software Solutions, con un proveedor específico de ADO.NET EF para SQLite.

 

 


Npgsql, con un proveedor para PostgreSQL.

 

 


Sybase SQL Anywhere, con soporte para BD’s SQL Anywhere a través de LINQ, eSQL y ADO.NET Data Services.

 

 


IBM, con un proveedor preparado para BD’s DB2, Informix y U2.

 

 

OpenLink Software, con un proveedor para de modo nativo a datos Virtuoso(SQL, XML y RDF) y tablas de Virtuoso vinculadas mediante fuentes externas ODBC y JDBC

 

 


Firebird, en versión beta, se trata de un proveedor de ADO.NET EF preparado para trabajar con BD’s firebird.