EntityFramework 4.3.0 Released

Recientemente salio a la luz la versión release de Entity Framework 4.3.0 y en la que ya podemos disfrutar de muchas características que seguramente estarán disponibles en la versión 5.0 que viene en camino.

Entre las principales características que podemos encontrar en versión están:

  • New Code First Migrations Feature: esta es una de las principales características de la nueva versión de EF y nos permite ir “migrando” nuestra base de datos creada con Code First a media que el modelo va cambiando. Esto quiere decir que, entre otras cosas, podemos recuperar una instancia determinada de la base de datos entre las distintas versiones (migraciones) que hayamos generado. En un próximo post vamos a ver como trabajar con esta nueva característica.
  • Removal of EdmMetadata table: como ya hemos visto, con Code First podemos crear la base de datos simplemente ejecutando la app. A la creación se le suman todas las ventajas del esquema de generación que forma parte de Migrations.
  • Data Annotations on non-public properties: por defecto Code First no incluye las propiedades protected, private o internal.  Si utilizábamos estos modificadores por medio de otras API, los Data Anottations en dichas propiedades eran ignoradas. En esta nueva versión se ha modificado esta situación por lo que las Data Anottations en esos casos serán procesadas.
  • More configuration file settings: ahora es posible definir muchas más caracteristicas sobre Code First en nuestro archivo de configuración. Todos los detalles aquí.

Instalación desde Nuget:

Instalando EF desde la consola de Nuget

Instalando EF desde la consola de Nuget

Más info sobré la instalación: http://nuget.org/packages/entityframework

Algunos enlaces interesantes sobre el tema:

Anuncios

MvcScaffolding

En esta oportunidad quiero mostrarles la librería MvcScaffolding que me pareció por demás interesante y que trabaja en conjunto con Entity Framework y ASP.NET MVC 3. La finalidad principal de esta librería es facilitarnos tareas comunes y repetitivas de desarrollo que nos quitan tiempo y productividad.

Pero antes de comenzar vamos a ver que significa el termino Scaffold en nuestro ambito:

El termino Scaffolding es utilizado en muchas tecnologías de software para representar una forma rápida de generar un esquema básico de software que se puede editar y personalizar.

Con esta librería a partir de un modelo definido y escribiendo solo un par de comandos vamos a poder generar: la base de datos, los controladores con sus métodos de acción y sus respectivas vistas. Qué beneficios nos trae esto? que nos vamos a evitar tener que hacer esas tediosas acciones repetitivas como por ejemplo los formularios de carga y edición para las entidades más simples de nuestro proyecto.

Para comenzar lo primero que vamos hacer es crear un nuevo proyecto ASP.NET MVC 3 e instalar los paquetes Eyntity Framework y MvcScaffolding.

Para instalar ambas librerías podemos utilizar la consola que nos provee Nuget (en este post solo voy a mostrar como instalar el paquete MvcScaffolding, aunque la instalación de EF es similar). Para eso vamos a la opción “Tools\Library Package Manager\Package Manager Console” la cual nos abrirá la consola en una pestaña. Ahí escribimos el siguiente comando “Install-Package MvcScaffolding” y presionamos “Enter“:

Instalando MvcScafollding

Instalando MvcScafollding

Una vez que tenemos las librerías que vamos a utilizar instaladas vamos a definir el mismo modelo que en anteriores post y que estará compuesto por las entidades Agenda y Evento:

1:     public class Agenda
2:     {
3:         public int AgendaId { get ; set ; }
4:         public string Propietario { get ; set ; }
5:         public DateTime FechaCreacion { get ; set ; }
6:
7:         public virtual ICollection <Evento> Eventos { get ; set ; }
8:     }
1:     public class Evento
2:     {
3:         public int EventoId { get ; set ; }
4:         public int AgendaID { get ; set ; }
5:         public DateTime Fecha { get ; set ; }
6:         public string Comentario { get ; set ; }
7:
8:         public virtual Agenda Agenda { get ; set ; }
9:     }

Si seguiríamos con el procedimiento normal para armar nuestra aplicación, el siguiente paso seria escribir el controlador y las acciones que necesitamos para trabajar con nuestra Agenda y por último crear cada una de las vistas, cierto?… la idea de MvcScafollding es automatizar dicho proceso y simplemente escribiendo un par de lineas de comando generar nuestras interfaces CRUD (es decir, el listado de registros y los formularios de alta, baja, detalle y modificación de la entidad).

Vamos a abrir nuevamente la consola desde el menú “Tools\Library Package Manager\Package Manager Console” y escribimos el siguiente comando: “Scafolld Controller Agenda” (podemos observar que la última palabra del comando corresponde al nombre de la clase Agenda) y presionamos ENTER. Haremos lo mismo con la otra clase de nuestro modelo que es Evento.

Generando las interfaces UI y DB a partir del modelo

Generando las interfaces UI y DB a partir del modelo.

Podemos observar que entre otras cosas nos genero el controlador, las vistas y hasta el contexto de la base de datos automáticamente 🙂 :

Archivos generados

Archivos generados

Ejecutemos nuestra aplicación y accedamos a la vista de la Agenda (o a la de Eventos) para observar que ambos formularios están totalmente funcionales y persisten en la base de datos 🙂

Formulario de alta de una agenda

Formulario de alta de una agenda

Sin embargo, si vamos a la vista de eventos, el combo para seleccionar la agenda a la cual pertenece no se ve correctamente, esto debido a que en el modelo no se especifico que propiedad de la agenda queremos visualizar:

Error al visualizar el combo de Agendas

Error al visualizar el combo de Agendas

Para corregir esto simplemente agregamos el atributo DisplayColumn (provisto por la librería DataAnottations) a la clase Agenda pasandole como parámetro el atributo que deseamos que se visualice, en nuestro caso el Propietario de la misma:

1: [DisplayColumn ("Propietario")]
2: public class Agenda
3: {
4:     public int AgendaId { get ; set ; }
5:     public string Propietario { get ; set ; }
6:     public DateTime FechaCreacion { get ; set ; }
7:
8:     public virtual ICollection<Evento> Eventos { get ; set ; }
9: }

Volvemos a ejecutar y tenemos listo el formulario:

Combo de agendas mostrando el atributo que elegimos

Combo de agendas mostrando el atributo que elegimos

Una de las cosas que me llamo la atención de esta librería es forma en que arma los listados (o vistas index) ya que agregó una columna que nos permite saber el número de eventos que tiene cada agenda:

Listado de agendas

Listado de agendas

Con lo que respecta a la base de datos, la librería MvcScafollding esta integrada con Entity Framework y por default trabajan con base de datos SqlExpress. Un punto importante a saber es que el nombre con que se genera la base de datos coincide con el nombre completo del DbContext, en nuestro ejemplo el nombre de la DB es el siguiente MvcScaffolding.Models.MvcScaffoldingContext.

Otra de las cosas que me llamo la atención, es que no encontraba la cadena de conexión a la base de datos por ningun lado. Luego de leer un poco, me encontré con que, si no se especifica la cadena de conexión en el archivo web.config, EF lo que hará es generar “dinamicamente” la conexión a la base de datos utilizando el nombre del DbContext que estará corriendo sobre la instalacia local del SqlExpress (en mi caso .\SQLExpress). Recordemos que EF trabaja con el esquema de convenciones sobre el de configuraciones.

Cadena de conexión

Cadena de conexión

Pero bien podríamos modificarlo para que trabaje con SqlCE simplemente modificando la cadena de conexión dentro del archivo web.config como explicamos en este post.

Antes de finalizar el post, les voy a nombre algunas de las caracteristicas que ofrece MvcScaffolding:

  • Soporte para proyectos en C # como en VB.
  • Soporte para los ViewEngines Razor y ASPX.
  • Se pueden personalizar el código generado editando los templates T4.
  • Personalizar la lógica utilizada para generar las salidas modificando la lógica del PowerShell y de los templates T4.

Espero que les haya servido y que sigan investigando sobre esta librería que tiene muchísimo más para ofrecerles.

Entity Framework 4.1 CF y Lazy Load

Para finalizar esta serie de post sobre Entity Framework 4.1 CF, vamos a hablar de una nueva caracteristica: soporte de Lazy Load (Carga Diferida).

Comencemos con una definición general de Lazy Load para que nos demos una mejor idea de que estamos hablando:

El Lazy Loading es un patron de diseño util y simple que se basa en ir cargando los distintos componentes de una clase cuando los vamos usando.

Ahora vamos a ver como trabaja este patrón de diseño dentro del framework EF CF 4.1.

En la definición anterior explica que Lazy Loading tiene como finalidad ir cargando los distintos componentes de una clase a medida que lo vamos usando. Esos componentes en EF se representan por medio de las llamadas propiedades de navegación, las cuales nos proporcionan una forma de navegar de una asociación o relación entre dos tipos de entidades, retornando una referencia a un objeto (si la relación es de cero a uno o uno a uno) o una colección (si la relación es de uno a muchos).

En nuestro ejemplo las propiedades de navegación son: Eventos que pertenece a la clase Agenda y Agenda que pertenece a la clase Evento:

1:     public class Agenda
2:     {
3:         public int AgendaId { get ; set ; }
4:         public string Propietario { get ; set ; }
5:         public DateTime FechaCreacion { get ; set ; }
6:
7:         public virtual ICollection <Evento> Eventos { get ; set ; }
8:     }
1:     public class Evento
2:     {
3:         public int EventoId { get ; set ; }
4:         public int AgendaID { get ; set ; }
5:         public DateTime Fecha { get ; set ; }
6:         public string Comentario { get ; set ; }
7:
8:         public virtual Agenda Agenda { get ; set ; }
9:     }

Notece que por convención dichas propiedades son marcadas como virtual (si no las marcamos de esta forma, no podremos aprovechar las ventajas de LazyLoad).

Antes de escribir nuestra primer linea de código, quiero comentarles que Lazy Loading en EF 4 viene habilitada por default. Esto no es del todo apropiado, sobre todo cuando el volumen de datos es demasiado grande o en el caso de que solo quiera recuperar, por ejemplo, un listado de agendas, donde no me interesa conocer todos sus eventos asociados. Para evitar esto, vamos a decirle al DbContext que por defecto esta característica – LazyLoadingEnabled – venga des-habilitada. Entonces modificamos el constructor de nuestro DatosContext:

1: public class DatosContext : DbContext
2: {
3:     public DbSet<Agenda> Agendas { get; set; }
4:     public DbSet<Evento> Eventos { get; set; }
5:
6:     public DatosContext() : base("name=DatosContext") 
7:     {
8:         this.Configuration.LazyLoadingEnabled = false; 
9:     }
10: }

Ahora sí, ya tenemos nuestro entorno listo, comencemos!

Lo primero que debemos hacer es crear y grabar una agenda y luego asignarle un par de eventos (de esta forma podremos visualizar mejor los ejemplos). Una forma simple de realizar esto es sobre-escribir el método Seed() de la clase DatosInitializer tal como lo explicamos en el primer post de esta serie.

Ya conocemos la forma en que se relacionan nuestras entidades, por lo tanto vamos a hacer uso del método Include() que nos proporciona la clase DbQuery. También podemos hacer uso de la extensión Include() provisto por DbExtensions (para este caso recordemos importar System.Data.Entity).

Include() es el método que nos permite obtener de una consulta el set completo de datos de una entidad y de todas sus relaciones.

Generalmente para recuperar la lista de alguna entidad (en nuestro caso de agendas) escribimos la siguiente consulta:

1: public ActionResult Index()
2: {
3:     var agendas = datos.Agendas.ToList();
4:
5:     return View(agendas);
6: }

Sin embargo, esto no nos recupera la lista de eventos asociados a cada agenda (siempre y cuando hayamos desactivado la característica de Lazy Loading). Inspeccionando la primer agenda de la lista podemos afirmar esto:

Inspeccionando objetos obtenidos con EF4.1 sin LazyLoad

Inspeccionando objetos obtenidos con EF4.1 sin LazyLoad

Para poder recuperar la agenda y sus eventos asociados debemos hacer uso del método Include() donde le pasaremos como parametro la propiedad de navegación de la cual queremos obtener los datos:

1: public ActionResult Index()
2: {
3:     var agendas = datos.Agendas.Include("Eventos").ToList();
4:
5:     return View(agendas);
6: }

Ahora vemos los mismos objetos obtenidos con LazyLoad:

Inspeccionando objetos obtenidos con EF4.1 con LazyLoad

Inspeccionando objetos obtenidos con EF4.1 con LazyLoad

Como observamos, se han recuperado también los Eventos de la agenda.

Para finalizar veamos algunos ejemplos más de lo que podemos hacer con EF y Lazy Load:

1:// Recupero todas las relaciones entre agenda y eventos utilizando DbQuery.
2:// La asociación se especifica por medio de un string.
3:var ag = datos.Agendas.Include("Eventos").ToList();
4:
5:// Recupero todas las relaciones entre agenda y eventos utilizando DbExtensions
6:// La asociación se especifica por medio de una expresion lambda.
7:var ae = datos.Agendas.Include(e => e.Eventos).ToList();
8:
9:// Recupero una agenda creada en el día de hoy y sus eventos.
10:var a1 = datos.Agendas
11:          .Where(a => a.FechaCreacion == DateTime .Now)
12:          .Include(e => e.Eventos)
13:          .FirstOrDefault();

Espero que le haya sido de utilidad.

Entity Framework 4 CF y DataAnnotations

Vamos a continuar con el post anterior sobre EF 4.1 CF y en este caso ver un poco más en profunidad como se integra con el mecanismo de validación provisto por ASP.NET MVC denominado DataAnnotations.

Lo primero sera recordar como teniamos definida la clase Agenda y como EF contruyo la tabla Agenda a paritr de dicho modelo:

1:     public class Agenda
2:     {
3:         public int AgendaId { get ; set ; }
4:         public string Propietario { get ; set ; }
5:         public DateTime FechaCreacion { get ; set ; }
6:
7:         public virtual ICollection <Evento> Eventos { get ; set ; }
8:     }

El esquema de la tabla generada es el siguiente:

Esquema de la tabla Agenda

Esquema de la tabla Agenda

Como vemos en las propiedades de cada columna, el campo Propietario acepta valores nulos, y es lógico segun lo que definimos en nuestro modelo. En cambio el campo FechaCreacion no lo es, ya que el tipo de datos sobre el cual se armo es DateTime y el mismo no admite valores nulos.

Ahora bien, supongamos que por algun motivo necesitamos que el propietario se deba cargar de forma obligatoria, si bien este modelo sigue sirviendo, nada nos asegura que este dato siempre sea grabado en la base de datos. Entonces que mejor forma de asegurarnos esto que deshabilitando la propiedad Allow Nulls en la tabla. Pero si solo lo hacemos en la base de datos, puede darse el caso que alguna instancia de nuestro modelo venga con dicho atributo nulo, y al momento de grabar tengamos uno de dos problemas: o una excepción porque el campo es nulo, o se graba un espacio en blanco en dicho registro.

Por lo tanto, la mejor opción es aplicar ambas validaciones: a nivel DB y a nivel modeloASP.NET MVC provee una interesantisima libreria que nos permite aplicar reglas de validación sobre nuestro modelos, estas reglas luego podemos replicarlas en cada controlador y vista en donde sea utilizado el modelo.

Esta librería es DataAnnotation y las normas que podemos definir se aplican como atributos de las clases, generalmente a nivel de las propiedades. En nuestro caso, y sin complicarla demasiado, vamos a marcar la propiedad Propietario como requerida (Required):

1: using System.ComponentModel.DataAnnotations;
2:
3: namespace MvcAndEF.Models
4: {
5:     public class Agenda
6:     {
7:         public int AgendaId { get ; set ; }
8:         [Required]
9:         public string Propietario { get ; set ; }
10:         public DateTime FechaCreacion { get ; set ; }
11:
12:         public virtual ICollection<Evento> Eventos { get ; set ; }
13:     }
14: }

Lo mas interesante de esto, es que DataAnnotations se integra perfectamente con EF4 y este último al detectar una propiedad como requerida, modifica las estructura de la base de datos deshabilitando en ese campo la propiedad Allow Nulls, evitando de esta forma que se ingresen valores nulos en dicho campo, y asi asegurarnos que ese dato siempre estara disponible en el registro.

Nuevo esquema de la tabla Agenda

Nuevo esquema de la tabla Agenda

Además ya tendremos nuestra validación funcionando en el formulario web:

Validación web

Validación web

Espero que les haya sido de utilidad!

Introducción Entity Framework 4.1 Code Firts

La versión 3.5 SP1 del framework .NET nos proveia de una biblioteca ORM llamada Entity Framework. Esta primera versión recibió varias criticas por parte de los desarrolladores, las cuales por suerte fueron escuchadas por el equipo de .NET. Es por este motivo que junto a la salida de .NET 4 apareció una versión mejorada llamada Entity Framework 4.1.

Entre las mejoras que se incluyen en esta nueva versión se encuentran: el manejo de clases POCO, soporte para Lazy Load, mejor calidad en las querys SQL generadas, mayor compatibilidad con Linq entre otras más.

En este post vamos a trabajar con una nueva caracteristica de EF llamada Code Firts (cuya traducción valida prodía ser “Partiendo del código“) y cuyo punto fuerte es que partiendo de nuestras clases del dominio ya podemos crear nuestro modelo ORM. Todo esto sin preocuparnos por la creación de la base de datos, el mapeo entre las entidades y la DB, los archivos XML o editores y todas las configuraciones afines.

Pero vayamos por parte, antes de comenzar con un ejemplo, vamos a crear un proyecto ASP.NET MVC 3 y agregar las referencias a esta librería. Para poder trabajar con EF 4.1 Code First antes vamos a tener que instalar el componente EFCodeFirst y podemos hacerlo de una manera muy sencilla utilizando Nuget (en la pestaña online\all buscamos dicho componente e instalamos).

Instalando EF4.1 desde Nuget

Instalando EF4.1 desde Nuget

Finalizada nuestra instalación se nos abrirá un archivo ReadMe con algunos comentarios sobre el producto y se habrán agregado a la solución los assemblies correspondientes.

El segundo paso sera crear las entidades del modelo, en este ejemplo vamos a trabajar con dos entidades muy simples, la primera representara una agenda y la segunda eventos de la misma. Estas clases a crear son objetos simples denominados POCO en el ambiente .NET (es importante que estas clases POCO respeten algunas convenciones que no son para nada complejas y que nos permitirán trabajar con EF).

Es el turno de definir las clases que compondran nuestro modelo:

1:     public class Agenda
2:     {
3:         public int AgendaId { get ; set ; }
4:         public string Propietario { get ; set ; }
5:         public DateTime FechaCreacion { get ; set ; }
6:
7:         public virtual ICollection <Evento> Eventos { get ; set ; }
8:     }

1:     public class Evento
2:     {
3:         public int EventoId { get ; set ; }
4:         public int AgendaID { get ; set ; }
5:         public DateTime Fecha { get ; set ; }
6:         public string Comentario { get ; set ; }
7:
8:         public virtual Agenda Agenda { get ; set ; }
9:     }

Algo interesante a comentar de estas entidades es que las propiedades definidas como virtual corresponden a propiedades de navegación, y son aquellas que se pueden cargar en “diferido” (en otro post vamos a ver de que se trata esto).

El segundo paso será crear un contexto que nos permita realizar operaciones CRUD sobre nuestras instancias de Agenda y Evento. Para esto vamos a crear una clase llamada DatosContext que derive de DbContext y que contendra dos propiedades publicas (una por cada entidad del modelo que hemos creado) que seran del tipo DbSet<T>:

1: using System.Data.Entity;
2:
3: namespace MvcAndEF.Models
4: {
5:     public class DatosConext : DbContext
6:     {
7:         public DbSet<Agenda> Agendas { get ; set ; }
8:         public DbSet<Evento> Eventos { get ; set ; }
9:     }
10: }

Como ya se habran dado cuenta, estas librerias pertenecen a System.Data.Entity y son provistas por EF4.1. Las clases DbContext y DbSet nos permitiran realizar las operaciones relacionadas con el acceso a los datos.

A pesar de todo esto aún no hemos creamos la base de datos y mucho menos un mapeo con la misma, tampoco hemos utilizamos diseñadores y mucho menos realizamos configuraciones. Sin embargo ya estamos listo para trabajar! 🙂

Cómo es posible esto?… la respuesta es bastante sencilla, EF 4.1 Code First esta pensado para trabajar por convenciones en lugar de configuraciones (es por eso que al crear nuestras clases POCO tuvimos en cuenta ciertas consideraciones). El resto es historia conocida: cada clase se corresponderá con una tabla, cada propiedad una columna de la misma y cada instancia de dichas clases representará un registro en la base de datos.

Para ver en funcionamiento nuestro contexto, vamos a trabajar sobre un nuevo controlador llamado AgendaController y en las diferentes acciones armaremos consultas para persistir y recuperar los datos de nuestro modelo:

1: using System.Linq;
2: using System.Web.Mvc;
3: using MvcAndEF.Models;
4:
5: namespace MvcAndEF.Controllers
6: {
7:     public class AgendaController : Controller
8:     {
9:         DatosContext datos = new DatosContext();
10:
11:         public ActionResult Index()
12:         {
13:             var agendas = from a in datos.Agendas
14:                           select a;
15:
16:             return View(agendas.ToList());
17:         }
18:
19:         public ActionResult Create()
20:         {
21:             return View();
22:         }
23:
24:         [HttpPost]
25:         public ActionResult Create(Agenda model)
26:         {
27:             if (ModelState.IsValid)
28:             {
29:                 datos.Agendas.Add(model);
30:                 datos.SaveChanges();
31:
32:                 return RedirectToAction("Index");
33:             }
34:
35:             return View(model);
36:         }
37:
38:         public ActionResult Edit(int id)
39:         {
40:             var agenda = datos.Agendas.Single(a => a.AgendaId == id);
41:             return View(agenda);
42:         }
43:
44:         [HttpPost]
45:         public ActionResult Edit(Agenda model)
46:         {
47:             if(ModelState.IsValid)
48:             {
49:                 var agenda = datos.Agendas.Single
50:                             (a => a.AgendaId == model.AgendaId);
51:                 agenda.Propietario = model.Propietario;
52:                 agenda.FechaCreacion = model.FechaCreacion;
53:
54:                 datos.SaveChanges();
55:
56:                 return RedirectToAction("Index");
57:             }
58:
59:             return View(model);
60:         }
61:     }
62: }

En cada uno de los métodos de acción podemos observar ejemplos de las consultas básicas: selección, inserción y actualización de una entidad. Lo siguiente será crear cada una de las vistas para dichos métodos (lo cual se los dejo de tarea).

Ya tenemos todo listo y aún seguimos sin noticias de la base de datos 🙂 . Pues bien, es hora de que hablemos un poco de ella.

Existen dos estrategias a seguir para definir la DB: la primera es crear el esquema de la base de datos con alguna herramienta, como por ejemplo SQL Management Studio. La segunda permitir que EF 4.1 la genere por nosotros!

Por supuesto que vamos a utilizar la última opción y para eso sera necesario que en el archivo de configuración web.config agreguemos una nueva cadena de conexión para nuestra futura base de datos (esta entrada deberá tener el mismo nombre que la clase DbContext que hemos creado, para nuestro ejemplo DatosContext):

1:  <connectionStrings>
2:  <add name="DatosContext"
3:  connectionString= "Data Source=|DataDirectory|Datos.sdf"
4:  providerName= "System.Data.SqlServerCe.4.0 "/>
5:  </connectionStrings>


Nota: en nuestro caso vamos a usar como proveedor SQL Server Compact Edition 4.0 pero podriamos utilizar SQL Sever o MySql con solo modificar dicho parámetro dentro de la cadena de conexión.

Ahora simplemente ejecutamos y ya podremos crear nuestras primeras entidades:

Nuestra app corriendo

Nuestra app corriendo

Entramos al alta de Agendas:

Formulario de alta

Formulario de alta

Y creamos nuestra primer entidad:

Agregando nuestra primer entidad

Agregando nuestra primer entidad

Como podemos ver, los datos se guardaron sin necesidad de tener que crear manualmente la DB. Validemos esto abriendo el explorador de soluciones:

Base de datos creada

Base de datos creada

EF para generar automaticamente nuestra base de datos buscara dentro del archivo de configuración una cadena de conexión que tenga el mismo nombre que la clase heredada de DbContext y utilizando esta información creará el archivo correspondiente:

Modelo sobre el cual EF se basa para crear la DB

Modelo sobre el cual EF se basa para crear la DB

Podremos inspeccionar la base de datos desde el explorador de servidores (para poder visualizar la DB creada con SQL Server CE 2.0 deberemos instalar previamente el Visual Studio 2010 SP1):

Estructura de la DB creada

Estructura de la DB creada

La tabla EdmMetadata contiene información acerca de la estructura de los objetos del modelo utilizados al momento de crear la base de datos.

Para finalizar, supongamos que tenemos que modificar el modelo, deberiamos redefinir nuestra DB cierto? por defecto EF4.1 al detectar una modificación en el modelo no modifica la estructura de nuestra DB, solamente el contenido de la tabla EdmMetadata.

Para solucionar esto tenemos distintas maneras de sincronizar el modelo con la base de datos: una es hacerlo de forma manual, modificando la estructura de la tabla/s afectadas. Sin embargo existe una manera mucho mas simple para el desarrollador y es por medio del método DropCreateDatabaseIfModelChanges que viene incluida en la libería de EF4.1.

Para esto debemos agregar la siguiente línea en el método Application_Start() del archivo global.asax:

1: Database.SetInitializer<DatosContext>
2:     (new DropCreateDatabaseIfModelChanges<DatosContext>());

Como bien lo dice su nombre, este mecanismo lo que hace es eliminar y volver a crear la base de datos, por lo que todos los registros previamente grabados se perderan. Sin embargo, una forma de solucionar este problema es insertar automáticamente registros cada vez que se genere la base de datos, y la forma de hacerlo es creando una nueva clase “inicializadora” (habré inventado una nueva palabra?) que herede de DropCreateDatabaseIfModelChanges<T> donde T sera DatosContext y en la cual vamos a sobre-escribir el método Seed():

1: public class DatosInitializer : 
2:              DropCreateDatabaseIfModelChanges <DatosContext >
3: {
4:     protected override void Seed(DatosContext context)
5:     {
6:         Agenda agenda = new Agenda ()
7:         {
8:             Propietario = "Sebis" ,
9:             FechaCreacion = DateTime .Now
10:         };
11:
12:         context.Agendas.Add(agenda);
13:     }
14: }


Ahora solo resta modificar la línea que hemos escrito anteriormente dentro de global.asax para que cada vez que se vuelva a generar la base de datos, se inserten dichos registros:

1: Database.SetInitializer(new DatosInitializer ());


Resumiendo, EF 4.1 CF me parece muy recomendable para utilizar en desarrollos de pequeña escala, y ademas facilita  enormemente ciertas tareas al desarrollador, como por ejemplo evitar muchas de las configuraciones que siempre molestan a la hora de ponerse a programar.

En la proxima entrada vamos a ver como podemos integrar los validadores de ASP.NET MVC (Data Anottations) con EF4.1.

Espero que les sea de utilidad!