Anotaciones sobre Entity Framework



No trabajo mucho con Entity Framework, la mayor parte de los proyectos en los que he trabajado he realizado consultas utilizando ADO.NET puro, es decir, lidio con objetos SqlConnection, SqlDataReader, SqlParameter y sus equivalentes para Oracle o MySQL. Y mis consultas SQL son hechas a mano.  En teoría, trabajando así, se obtiene una mayor velocidad a la hora de ejecutar consultas contra las bases de datos.

Debo reconocer que Entity Framework es una herramienta que la tengo ahí en mi equipaje virtual y que a veces la toco con la punta del pie pero no me animo a usarla demasiado. Sin embargo, reconozco que utilizar EF ayuda a incrementar la velocidad de desarrollo. Ya no tienes que estar pensando en construir sentencias SQL, o crear tantas validaciones y controles.

En mis últimos proyectos he utilizado ADO.NET, excepto en uno. Aquí algunas anotaciones sobre el uso de Entity Framework, entendiendo que ya sabes lo básico, o incluso más.

Ubicación de Entity Framework


En la mayoría de ejemplos sobre EF vas a encontrar que se agrega directamente al proyecto de inicio de la solución. Pero mi idea era poner EF en un proyecto tipo biblioteca de clases, es decir una DLL.

La cadena de conexión


Al hacerlo, sin embargo se presentan dos problemas o  casos. El primero es que debemos pasar la cadena de conexión al app.config o web.config desde el archivo de configuración de la librería hasta el propio del proyecto de inicio (web o desktop), sino al iniciar se mostrará un error diciendo que no existe una cadena de conexión para el Entity Framework.

La dependencia que no se copia


El segundo es más complicado. Ahora para tener claro, este segundo caso que menciono, es lo primero que te va a aparecer si colocas EF en una librería y lo llamas de otro proyecto.
No Entity Framework provider found for the ADO.NET provider with invariant name 'System.Data.SqlClient'. Make sure the provider is registered in the 'entityFramework' section of the application config file. See http://go.microsoft.com/fwlink/?LinkId=260882 for more information.

Ahora, la recomendación que encontraba como solución era instalar el EF en el proyecto de inicio. Pero ¿instalamos el EF en cada proyecto? ¿de que serviría entonces haberlo puesto originalmente en una librería y tener que instalarlo en cada proyecto que la referencie?

Un segundo consejo era copiar la librería EntityFramework.SqlServer.dll al proyecto que referencia. Y agregar esa librería como referencia. Lo que mejora la primera solución en algo pero igual hace dependiente a dos proyectos de la misma librería cuando debería ser una cadena, es decir la DLL donde está el EF debe ser referenciada por el proyecto Web o por el Winform, y no cada proyecto referenciar al EF.

Ahora, ese problema que tiene el Entity Framework ubicado en una biblioteca de clases no es inherente al EF. Ocurre en varios casos. Tienes un Proyecto X, que tiene dependencias de una librería sin usarla explícitamente desde el código. Luego tienes un proyecto Web o Windows que utiliza Proyecto X, y Visual Studio falla al copiar la dependencia implícita, y obtendremos un error en tiempo de ejecución cuando tratemos de ejecutar el proyecto.

Una mejor solución es utilizar un método auxiliar que sea llamado lo más cerca posible a la llamada de la dependencia, en el caso de Entity Framework colocarlo en el constructor de mi clase, ese método auxiliar simplemente hará una llamada a una de las clases contenida en la dependencia que no se copia al directorio local. Por eso, prefiero las referencias explicitas, que las dinámicas, que se crean en tiempo de ejecución, pero entiendo que son utilizadas y por eso necesarias.

No es mi idea o algo que ya me lo inventé. Esta idea es de Anders MalmGren. Este es el método auxiliar (que no solo sirve para Entity Framework):
public static class Util
{
public static void EnsureStaticReference<T>()
{
var dummy = typeof(T);
if(dummy == null)
throw new Exception("This code is used to ensure that the compiler will include assembly");
}
}

Y la llamada sería así:
static RepositoryBase() {
Util.EnsureStaticReference<System.Data.Entity.SqlServer.SqlProviderServices>();
}

Con eso se soluciona el problema, y ya puedes ejecutar el proyecto.

Eso es todo por ahora sobre mi nueva experiencia (otra vez) con Entity Framework, seguramente los expertos ya sabrán esto, pero espero les sirva a los novatos como yo.

 

 

Comentarios