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
|
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:
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 …
-
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.-
-
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.
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.
- 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.
-
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.
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.
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:
-
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.
-
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.
|
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!!
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.
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:
En cuanto al listado de proveedores, veréis que a día de hoy tenemos los siguientes con soporte para ADO.NET EF:
.png)
Devart, que ofrece soporte para ADO.NET EF para BD’s Oracle, MySQl y PostgreSQL.
.png)
Phoenix Software Solutions, con un proveedor específico de ADO.NET EF para SQLite.
.png)
Npgsql, con un proveedor para PostgreSQL.
.png)
Sybase SQL Anywhere, con soporte para BD’s SQL Anywhere a través de LINQ, eSQL y ADO.NET Data Services.
.png)
IBM, con un proveedor preparado para BD’s DB2, Informix y U2.
.gif)
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
.png)
Firebird, en versión beta, se trata de un proveedor de ADO.NET EF preparado para trabajar con BD’s firebird.
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.
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.
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.
Siguiendo con las pruebas de ADO.NET Entity Framework (ADO.NET EF) comenzadas en este post, en esta nueva entrega vamos a hablar de uno de los elementos de EF: Entity Client. Se trata de un nuevo proveedor de datos que aparece con EF y que permite realizar consultas a entidades de un modelo conceptual. Para ello emplea el lenguaje Entity SQL (eSQL) que permite realizar consultas al modelo independientemente de la tecnología de base de datos subyacente. Empecemos.
Entity Client
Lo primero que tenemos que hacer es añadir una referencia al espacio de nombres EntityClient.
Añadimos las correspondientes sentencias using relativas a los espacios System.Entity y System.Data:
|
using System.Data;
using System.Data.EntityClient;
|
A continuación vamos a definir una consulta al EDM mediante Entity Client:
|
var ecConexion =
new EntityConnection();
ecConexion.ConnectionString = “Name=AdventureWorksLTContext”;
var ecComando = ecConexion.CreateCommand();
ecComando.CommandText
= “SELECT VALUE p from AdventureWorksLTContext.Product AS p”;
ecConexion.Open();
var ecReader =
ecComando.ExecuteReader(CommandBehavior.SequentialAccess);
Console.WriteLine(“******Query******”);
Console.WriteLine(ecComando.ToTraceString());
Console.ReadLine();
Console.WriteLine(“******Resultados******”);
while (ecReader.Read())
{
Console.WriteLine(“Producto: {0}”, ecReader["Name"]);
}
ecConexion.Close();
Console.ReadLine();
|
Como vemos, lo que estamos haciendo en el código anterior es:
- Definir una instancia de EntityConnection que representa la conexión al EDM. Esta conexión está plenamente identificada por el nombre del EntityContainer (AdventureWorksLTContext), si bien podríamos especificar la cadena de conexión completa (referenciar a las tres capas que constituyen el EDM). Sin embargo, no necesitamos especificar la cadena de conexión completa dado que el EDM está en el mismo ensamblado que el consumidor.
- Definimos una instancia del objeto EntityCommand que representa la consulta que vamos a realizar al modelo. Esta consulta la estamos definiendo en Entity SQL (eSQL). De esta consulta destacaría que usa la palabra clave VALUE, lo que le indica al runtime que no envuelva el resultado de la consulta como una fila e datos.
- Abrimos la conexión al modelo.
- Ejecutamos el comando mediante un objeto de tipo EntityDataReader.
- Mediante reflexión y el método ToTraceString, obtenemos la consulta que se envía a la BD subyacente al modelo.
- Leemos el resultado de la ejecución del comando mediante el método Read() del objeto EntityReader.
- Cerramos la conexión al modelo.
Tras ejecutar el código anterior:
- Por un lado, tenemos la consulta enviada a la BD.
- Por otro, tenemos el resultado de la consulta.
Al igual que ocurre con T-SQL convencional, eSQL permite definir consultas parametrizadas. Por ejemplo, podemos realizar una consulta sobre la entidad Product aplicando un filtro a la columna Name:
|
Console.ReadLine();
Console.WriteLine(“******Consulta parametrizada******”);
ecComando.Dispose();
ecComando = ecConexion.CreateCommand();
ecComando.CommandText =
“SELECT p.Name FROM AdventureWorksLTContext.Product AS p ” +
“WHERE Length(p.Name)>@iLongitud”;
ecComando.Parameters.AddWithValue(“iLongitud”, 30);
ecReader =
ecComando.ExecuteReader(CommandBehavior.SequentialAccess);
Console.WriteLine(“******Query******”);
Console.WriteLine(ecComando.ToTraceString());
Console.ReadLine();
Console.WriteLine(“******Resultados******”);
while (ecReader.Read())
{
Console.WriteLine(“Producto: {0}”, ecReader["Name"]);
}
ecConexion.Close();
Console.ReadLine();
|
Como vemos en el código anterior:
- En primer lugar liberamos los recursos que usa el objeto EntityCommand.
- Creamos un nuevo comando que utiliza un parámetro.
- Le añadimos el parámetro al EntityCommand a través de la definición de un EntityParameter.
- Ejecutamos la consulta.
- Mostramos la consulta enviada.
- Ejecutamos la consulta.
Los resultados obtenidos en este caso son los siguientes:
Como veis, la API EntityClient permite crear rápidamente consultas a un EDM utilizando un estilo similar al tradicional ADO.NET.
