EF 4.1 Code First ¿Dónde está la base de datos?

Hola

Me voy a saltar el post pendiente que tengo sobre crear o comentar algún código existente sobre el algoritmo Hi/Lo para los Object ID en Entity Framework. El culpable de este salto es un inquieto colega de proyecto que se puso a probar un artículo que publicamos hace unos días por Twitter sobre MVC 3 con Repositorios e inyección de dependencias usando Entoty Framework.

El artículo no permite descargar el código del ejemplo, así que, gracias Oscar por ahorrarme el trabajo   

Después del prólogo y los agradecimientos, entramos en materia.

El problema, si le podemos llamar así, ya lo tenía anotado como uno de los temas a tratar en esta nueva aventura con Entity Framework. El código causante de todo el debate es este:

La parte que nos importa en la clase Db, la cual hereda del contexto, es la implementación del constructor que llama a la base pasando como parámetro la cadena “DemoDb2”. El parámetro que se le pasa al contexto, según el MSDN, identifica la cadena de conexión o el nombre de la base de datos asociada al modelo que vamos a usar. Este simple código, si no conoces qué hace Entity Framework con él, nos puede costar un “poquito de dolor de cabeza”.

Supongamos que vamos a nuestro archivo de configuración y definimos la siguiente cadena de conexión (Observe que he puesto “DemoDb” y no “DemoDb2)

 

…o simplemente olvidamos que debemos configurar el web.config  para indicar la cadena de conexión. Ejecutamos y “walaaa”    Nuestra aplicación funciona

Si voy a mi servidor en busca de la base de datos me encuentro con que no existe. Pues bien, si EF no encuentra la cadena de conexión o la misma es incorrecta, utiliza el SQL Express que tengamos instalado en local y con autenticación integrada de Windows, crea la base de datos.

Les juro que no estoy haciendo trampas, ninguna de las bases de datos que están tachadas es la del ejemplo 

En mi opinión, hubiera preferido que ocurriera un error y así darme cuenta que tenía algo mal, digamos que algo así…

 Editado: En los comentarios, Pablo Núñez  nos dice cómo lograr que EF pueda tener el mismo comportamiento que NH. (Gracias Pablo)

 

9 comentarios sobre “EF 4.1 Code First ¿Dónde está la base de datos?”

  1. Coincido en que el comportamiento por defecto debería ser menos agresivo. Aunque hay alternativas: se puede forzar el mismo comportamiento de NHibernate modificando Database.SetInitializer a un inicializador personalizado.
    Y para el típico caso en que el EF confunde el nombre de la ConnectionString con el nombre de la base de datos, hay una solución más sencilla:

    public Db() : base(«name=DbDemo2») { }

    Así dará una excepción si no encuentra el parámetro DbDemo2 en web.config. Más info en: http://social.msdn.microsoft.com/Forums/en-SG/adodotnetentityframework/thread/5756081a-8c75-4200-ae47-efdd7862efec

  2. A punto estuve de animarme a escribir yo algo sobre el tema pero me alegro de no haberlo hecho.

    Mucho más claro así y metiendo caña con NHibernate que yo no hubiera podido 🙂

    Lo mismo se podría poner el código para descarga para los interesados en probarlo…¿que opinas?

  3. @Pablo… Muchas gracias por el comentario..

    Es verdad que quería enfocar el artículo más a ese comportamiento por defecto, pero ya que estábamos y para ser justos, debí incluir cómo lograr q EF pudiera tener el mismo comportamiento que NH.

    Edito el artículo para indicar que en los comentarios podrán encontrar la solución.. 😉

    Gracias de nuevo…

    @Oscar, no publiqué el código porque aunque nos ha valido de ejemplo para ver este comportamiento de EF, no tiene mucho que ver con lo que queríamos destacar.

    Gracias a los dos por los comentarios.
    Salu2

  4. Esto es un tema que se ha comentado y mucho, pero en realidad «no es un problema», es una diferencia de convención, mucha gente cree que esto no debería ser automático, otra mucha gente cree que por defecto es una buena estrategia, etc… La suerte es que como muy bien comento Pablo Nuñez en este caso puedes cambiar la convención estableciendo un nuevo IDatabaseInitializer..

    Nota: De todas formas, porque en el post no queda claro, el nombre que EF busca por defecto en las cadenas de conexiones es el nombre completamente cualifcado de tu unidad de trabajo, incluyendo namespace…

    Unai

  5. Gracias por el comentario @Unai.. 😉

    Al principio del post comentaba que este comportamiento no era precisamente un problema y estoy de acuerdo en ello…

    Quizás para quienes trabajen en local contra su SQL Express como gestor de BD, seguro que esto es genial, pero si se trabaja contra un servidor y en equipo el problema puede ser mayor o, al menos nos tomará unos minutos hasta que nos demos cuenta.

    Lo importante creo que es conocerlo, ya evitarlo o no, seguro dependerá de las necesidades de cada proyecto.

    Gracias por la aclaración sobre la cadena de conexión.. no lo sabía..

    Salu2

  6. Omar, si lo que quieres es trabajar contra otro servidor o en otro equipo por defecto también puedes utilizar la clase Database tal y como sigue:

    Database.DefaultConnectionFactory = new SqlConnectionFactory(«Server=.;Integrated Security=false»);

    Con esto le estarás diciendo a EF cual es la instancia por defecto a utilizar…en este caso (local) no SQLEXPRESS como es por defecto.

    Unai

Responder a anonymous Cancelar respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *