Ensamblados con Model incrustado

En este blog Hemos hablado de aplicaciones que usan un solo Model del Entity Framework. Sin embargo en la vida real, esto no es así de simple. Casi siempre los proyectos deben incluir bibliotecas, y estas pueden ser desarrolladas por varias personas, lo que ocasiona que cada proyecto pueda tener su propio Model.

Como tal vez ya han descubierto, la cadena de conexión se almacena originalmente en el proyecto donde se genera el MODEL, cuando este proyecto se compila y se genera un DLL, la cadena de conexión se debe copiar del proyecto original y agregarse al config correspondiente al proyecto en el cual se han referenciado las DLL’s.

En nuestro proyecto hemos usado una implementación genérica del Repositorio, usando el patrón de unidad de trabajo, para optimizar el uso se agrego la funcionalidad de LAZZY LOAD, lo que ocasiona que debamos usar un mecanismo de REFLECTION para crear instancias del MODEL correspondiente:

Al usarla en un solo proyecto no tuvimos problemas, sin embargo cuando las DLL’s resultantes de todos los proyectos, comenzaron a mezclarse para ser usadas por una sola aplicación, la situación se torno inestable.

Detectamos que cierta combinación de DLL’s que dependían entre sí ocasionaban que de forma errática nuestra aplicación presentara un error, el cual por si solo, no nos daba la pista de por dónde buscar.

Tras depurar nuestro código pudimos detectar que el problema se presentaba en la línea del constructor, dentro del código generado donde se creaba la instancia del MODEL correspondiente:

y si a este dato le uníamos el mensaje de error que habíamos recibido, entonces ya sabíamos dónde estaba el error.

 

ARCHIVOS DEL MODEL

El EF se forma de tres archivos, que definen su estructura; estos archivos pueden ser parte del DLL final o estar de forma externa; y según la documentación si los generábamos de forma externa y no los incluíamos en el proyecto, entonces fallaba. Después de revisar los proyectos, vimos que este no era el caso, nuestro EF no las generaba de forma externa, esto se puede verificar en las propiedades del Model:

Otro punto importante es saber si se había manipulado el código generado del Model, lo que tampoco fue nuestro caso; también se recomienda revisar los archivos config, por si habíamos modificado la cadena de conexión. Dado que por nuestra implementación habíamos estado trabajando con las cadenas de conexión, nos dimos a la tarea de revisar las cadenas de conexión, verificamos que estén escritas de forma correcta, no hubo problema.

Incluso alguien recomendó eliminar el Model y volverlo a generar, este último detalle soluciono el problema, pero no en todos los casos; además no me parece que sea correcto tener que volver a generar el Model cada vez que se presentara este problema.

Las pistas nos indicaban que el problema se estaba generando en los archivos que forman el Model. Pero en qué lugar de nuestro código se hace referencia a estos? Como sabe que archivos están relacionados?...

Si tuvieron la curiosidad de ver la cadena de conexión que se genera automáticamente, habrán notado que no es la cadena tradicional que hemos usado antes. Esta empieza con la palabra “metadata” que después de todo a resultado ser nuestra principal sospechosa. Y si seguimos la pista podremos ver que hay tres nombres diferentes dentro de su ámbito:

1. Modelo.csdl

2. Modelo.ssdl

3. Modelo.msl

Al principio de cada uno podemos ver una cadena repetida: res://*/ el asterisco se usa para omitir el nombre especifico del DLL en cual se encuentra nuestro Model. De esta forma buscara en todos los Assemblies que estén cargados:

Esta parte me llevo a preguntarme:

Que pasaría si elimino los nombres específicos y en vez de estos uso únicamente: res://*/?

La cadena quedo así:

Cual fui mi sorpresa al ver que mi código paso sin ningún problema de la línea donde se detenía. Tal vez sea un poco más lento, pero soluciono el problema de la mezcla de bibliotecas y Modelos.