Después del post previo en el que explique cómo logre que funcionara en MVC un Model Incrustado en un DLL; tratamos de aplicar el mismo truco para otro proyecto, un Framework, que está formado de varias bibliotecas, cada una con su Model independiente incrustado, pero no funciono.
Así que la investigación continúo…
En Internet hay muchos lugares donde se habla del tema, hay muchos consejos, al parecer a algunas personas les funciona a otra no, como en nuestro caso. Dado que no hay suficiente información que provenga de un lugar de confianza o al menos que pudiera hablar con el conocimiento de causa, como Microsoft, nos avocamos a probar de todo lo que encontramos.
Podemos hacer un resumen de algunas de las cosas que hicimos:
- Limpiar los proyectos usando el contextual dentro del Visual Studio
- Verificar que no quede nada en ambas carpetas dentro del BIN (ni en Debug, ni en Release), si algo hubiera quedado, se debe eliminar.
- Revisar las referencias, para verificar hacia donde se dirigen, deben ser a las DLL’s en la carpeta donde colocamos los assemblies compartidos, no a las carpetas internas del BIN; aun que después se cambie, al menos verifíquenlo la primera vez.
Después de todo, al parecer el origen del problema es la cadena de conexión.
Cuando se trabaja con diferentes proyectos con Model (EF) dentro de cada uno, la cadena de conexión que se utiliza al crear este Model, se almacena en el archivo Config correspondiente. Si queremos usar estas DLL’s en otro proyecto, debemos copiar las cadenas de conexión al archivo Config de nuestra aplicación.
En este punto pensamos que usar una sola cadena de conexión sería lo ideal, y esto requiere que usemos el EntityConnectionStringBuilder, en una solución similar a la que expuse en este otro post.
Que debemos modificar?
Lo último que identificamos durante la investigación está relacionado con dos puntos:
- Verificar que el nombre físico del archivo edmx sea diferente, en cada proyecto.
- Escribir explícitamente el nombre del archivo en la cadena de conexión, en la sección del Metadata.
El primer punto recomendaba verificar que el nombre físico del archivo del Model fuera distinto en cada proyecto, en nuestro caso. En nuestro caso todos se llamaban de igual manera.
El segundo punto requería que escribiéramos en la sección de la cadena de conexión, donde se refiere a los archivos que definen el Model, los mismos nombres que le asignamos al archivo físico. De esta forma sustituiríamos, el nombre que aparece en la cadena de conexión por el que nosotros le asignamos al archivo.
Lo malo es, que al hacer esto, tendríamos varias cadenas de conexión. Una cadena de conexión diferente por cada Proyecto.
La Solución
Revisando los foros de MSDN, encontré uno donde se trataba el tema (desgraciadamente no he podido volverlo a encontrar, para ofrecerles el link y así poder reconocer los créditos); la respuesta del Especialista de Microsoft, fue que si queríamos evitar el uso de múltiples cadenas de conexión, la solución es crear un método que las construya usando los datos necesarios en la sección del Metadata.
Para evitar que la cadena de conexión este inmersa en el código, podemos usar algunas variables en el Config,esto nos permitiría cambiarlas en tiempo de ejecución, sin necesidad de volver a compilar, las variables deberían ser para El nombre del Servidor, la base de datos, el usuario y la contraseña.
La combinación de lo los dos puntos con este método que crea la cadena de conexión al parecer soluciono nuestro problema.
El método quedo así: 
En el método es muy importante tener en consideración el nombre de la carpeta en la cual se almacena el Model, ya que formara parte del NameSpace. En nuestro caso es Model, si ustedes almacenan el archivo Físico del Model en otra carpeta, este dato debe coincidir con él, para que el método pueda formar la cadena de conexión de forma apropiada para sus proyectos.
Esta cadena de conexión se le debe pasar al constructor de nuestro Model, para que no la busque en el archivo Config.
El poder del código solo es completo, si tenemos el conocimiento de como usarlo.
No hay comentarios:
Publicar un comentario