EF 4.3 Beta 1: más madera….y un pequeño extra…

Cuando se publique este post habrá salido ya el anuncio de la primera beta de ADO.NET EF 4.3 en el blog del equipo de producto de ADO.NET. Los que me leeis con asiduidad sabréis que si solamente es para poner una reseña no suelo escribir una entrada o sea que trataré de dar mi punto de vista sobre esta nueva beta y algunas cosillas extras que no salen publicadas en los diferentes walkthrough.

Bien, antes de empezar con las novedades, que enumeraremos a continuación, es importante decir que esta será la última versión de EF hasta la llegada de EF 5.0 con la siguiente entrega de .NET Framework, en la que el código base, es decir, System.Data.Entity, por fin abrirá más puertas para introducir más y más importantes mejoras. Como acabamos de comentar, de entre las novedades mñas importantes que podemos encontrar en esta version tenemos los siguientes elementos, para el resto de información, revisar la entrada del grupo de producto aquí.

 

  • Inclusión del paquete de Migraciones dentro del código base de EntityFramework.dll
  • Resueltos un par de bugs, revisar el post del grupo de producto
  • Una nueva sección de configuración que nos permitirá establecer inicializadores y configurar la DefaultConnectionFactory que utilizaremos por defecto

 

Migraciones es ahora parte de EF

 

Como ya comentamos en esta anterior entrada desde esta versión EF incluye por defecto el paquete de migraciones, sin tener, como hasta ahora que incluir en NuGet EntityFramework.Migrations como hasta ahora. En realidad, el funcionamiento es el mismo que hasta ahora, pero, con unos pequeños ligeros cambios en los comandos de power shell y la eliminación de la convención IncludeMetadataConvention. Como siempre, lo mejor es verlo todo en la práctica o sea que vamos a ello. Crearemos, como hacemos habitualmente, un proyecto tonto de demo que nos permitirá ir viendo cosillas.

 

Lo primero será incluir el paquete de EF 4.3, puesto que es beta, al igual que se ha hecho con otros paquetes, tenemos que incluir en el comando de instalación la opcion IncludePreRelease aunque también suelen funcionar PreRelease y Pre simplemente.

1

Una vez incluído el paquete de la beta, crearemos nuestra unidad de trabajo, un ejemplo sencillo, tal y como hacemos habitualmente:

 








































 

Tal y como sabréis todos a estas alturas, si utilizaramos la unidad de trabajo anterior, se nos generaría una nueva base de datos para el mode2lo dado, ahora, este proceso será el mismo, pero con un importante cambio y es que el proceso de creación de la base de datos se hace utilizando el API de Migrations, para ello basta con fijarse que ya no tenemos la tabla de metadata típica y sin embargo, en las tablas de sistema podemos ver una nueva llamada __MigrationHistory, tal y como se ven en la imagen de la derecha.

 

Bueno, aunque esto sea así, por defecto, el sistema de migraciones no está habilitado en nuestros cambios de dominio, para ello, tenemos que ejecutar el comando Enable-Migrations. Este comando, tiene el mismo efecto que tenía en anteriores versiones incluir el paquete de migraciones, es decir, nos agrega una nueva carpeta llamada Migrations en la que tendremos la configuración del sistema de migraciones y se incluirá el código de las distintas migraciones que vayamos haciendo. En realidad aquí no hay nada nuevo a lo que ya conocíamos, aunque para ser sincero tampoco he revisado el conjunto de propiedades que DbMigrationsConfiguration pone a nuestra disposición.

 

 

 

 

 

Bien, una vez habilitadas las migraciones pasaremos a crear(actualizar) la base datos, otra vez, como ya sabíamos tenemos el comando Update-Database con sus diferentes opciones, os recomiendo mirar el get-help Update-Database –detailed para una completa información de todo lo que podemos hacer. Por ahora, al habilitar las migraciones ya tendremos la base de datos generada y por lo tanto, el comando nos dirá que no tiene tareas pendientes o sea que empezaremos agregando una nueva propiedad a Blog, por ejemplo CreationDate, como vemos en el siguiente fragmento.

 














 

Una vez agregada esta propiedad, agregaremos una migración, para ello, usaremos otra vez el ya conocido comando Add-Migration, el cuál, incluye  en la carpeta de migraciones el código de la nueva migración, que yo he llamado AddedCreationDate y que contiene algo similar a lo siguiente:

 
































































Por supuesto, también, como ya sabrá de anteriores entradas podemos hacer otras tareas como la creación de índices etc, como vemos en la lista de métodos que DbMigration pone a nuestra disposición:

 

  • AddColumn
  • AddForeignKey
  • AddPrimaryKey
  • AlterColumn
  • CreateIndex
  • CreateTable
  • DropColumn
  • DropForeignKey
  • DropIndex
  • DropPrimaryKey
  • DropTable
  • MoveTable
  • RenameColumn
  • RenameTable
  • Sql

La nueva sección de configuración

 

Como comentábamos  antes,aquí va el punto extra, y es que EF 4.3 pone a nuestra disposición a una nueva sección de configuración, EntityFrameworkSection, gracias a la cual podremos configurar desde el DefaultConnectionFactory que queremos tener por defecto ( antes teníamos que recurrir a Database.DefaultConnectionFactory ) hasta los inicializadores que queremos tener por defecto. A continuación os pongo un fragmento de una sección de configuración sobre un contexto de trabajo en el que se establece un inicializador y en la que además se establece una factoria de conexión por defecto.

 

4

 






































 

Como veis el equipo de ADO.NET está trabajando duro y esto es algo que podemos ver de forma temprana gracias a que los paquetes de EF nuevos no forman parte del Framework. Os imaginais que pasaría si EF se fuera a un modelo como el de MVC en el que no tienen una dependencia con el framework… ummmm

 

Saludos

Unai

4 comentarios sobre “EF 4.3 Beta 1: más madera….y un pequeño extra…”

  1. >Os imaginais que pasaría si EF se fuera a un modelo como el de MVC en el que no tienen una dependencia con el framework

    Eso sería ideal, y aplica a EF y a multitud de otras apis que están en el propio framework. Personalmente no veo la razón a tenerlo todo tan atado. Esas APIs deberían evolucionar independientemente, con ciclos cortos, para adaptarse más ágilmente a lo que se pida, en lugar de estar atados a ciclos largos de >2 años que es lo que se tarda en renovar el fwk + VS.
    Para mi sería la solución ideal, no solo de EF, sino de WPF, Webforms y el resto de APIs que puedan haber. Si MVC fue la prueba, yo creo que fue exitosa.

    Un saludo!

Responder a etomas Cancelar respuesta

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