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.

ADO.NET Entity Framework: Actualizaciones en la documentación!

Microsoft acaba de realizar una serie de actualizaciones de la documentación de ADO.NET Entity Framework (ADO.NET EF) enfocadas a resolver preguntas frecuentes en el trabajo con entity keys, edición manual de edmx y otros aspectos:

ADO.NET Entity Framework: + proveedores!

El goteo continuo de proveedores de terceros con soporte para ADO.NET Entity Framework (ADO.NET EF) sigue, y en esta ocasión os dejo información relativa a los dos últimos proveedores de los que he tenido constancia:

  • El primero de ellos apareció a finales del mes de octubre pasado, se trata del soporte por parte de Sybase en la versión SQL Anywhare 11 de ADO.NET EF en su proveedor ADO.NET. Podéis obtener más información sobre el soporte de ADO.NET EF en SQL Anywhere 11 en este enlace.
  • El segundo proveedor, y en mi opinión, el más relevante liberado hasta ahora es el nuevo proveedor de ADO.NET de IBM que incluye soporte para EF y para las bases de datos DB2, Informix y U2. Podéis obtener más información sobre el soporte de EF por parte de los proveedores ADO.NET de IBM en este enlace.

Nuevo Npgsql’s ADO.NET Provider para PostgreSQL con soporte para ADO.NET Entity Framework!

Parece que los fabricantes de software siguen trabajando a todo tren en crear nuevos proveedores para ADO.NET Entity Framework que permitan utilizar esta tecnología sobre motores de bases de datos existentes. en este caso, Npgsql ha liberado la versión 2.0 de su proveedor de ADO.NET para PostgreSQL. La novedad de esta versión es que incluye soporte para ADO.NET EF. Para más información podéis consultar este post del equipo de ADO.NET EF y este enlace de la web PgFoundry.

LINQ To Oracle y LINQ To MySQL!

El pasado jueves realizamos en Santander un evento de Depuración y Optimización Avanzada de aplicaciones, pero no sólo se hablaron de estos temas durante todo el tiempo que duró la sesión…la verdad es que es una satisfacción ver como cada vez hay más y más gente interesada en probar y usar las últimas tecnologías sacadas del horno por Microsoft. Si recordáis, hace un tiempo os contaba la disponibilidad de los primeros proveedores de terceros para ADO.NET Entity Framework suministrados por la empresa Devart. El caso es que uno de los asistentes al evento me preguntó si sabía si Oracle estaba trabajando en su propio proveedor nativo para ADO.NET EF, puesto que no hay mucha información al respecto…lógicamente, yo no le pude sacar de dudas puesto que desconozco si en Oracle están trabajando en este proveedor (entiendo que sí, porque va a ser una demanda muy típica de todos aquellos que desarrollan en .NET sobre Oracle…el caso es que, aunque no pude resolver la duda planteada, a mi me sirvió la conversación para enterarme que Devart está trabajando en dos extensiones de LINQ para trabajar con Oracle y MySQL con la misma filosofía con qué LINQ To SQL nos permite trabajar con BD’s SQL Server…se tratan de las extensiones LINQ To Oracle y LINQ To MySQL incluidas dentro de su producto OraDirect.Net. Estas extensiones están actualmente en  Beta, y además en un futuro tendremos extensiones para BD’s PostgreeSQL y SQLite.

Podéis descargaros las extensiones de LINQ para Oracle y MySQL de este enlace.