UML con Visual Studio 2010

Quienes trabajamos en alguna de las ramas de la ingeniería hemos encontrado en las representaciones gráficas un elemento valioso de comunicación y documentación. En nuestro día a día utilizamos modelos gráficos para muchas de nuestras tareas, por ejemplo cuando tenemos que diseñar las tablas de nuestras bases de datos o al momento de armar un diagrama de clases que sera parte de la lógica del sistema. Continuamente “dibujamos” modelos, ya sea escritos en papel o con herramientas informáticas.

Ahora bien, hagamos un poco de historia sobre el modelado gráfico dentro del ciclo del desarrollo de software. A mediados de los 80’s, la elaboración de los modelos se convertía en una tarea cada vez  mas compleja. En parte debido a que los sistemas crecían en su  arquitectura  y que la tecnología continuamente brindaba nuevas posibilidades y capacidades de comunicación, almacenamiento y procesamiento entre otras.

Sumado a todo esto, la  falta de un estándar en la forma de elaborar estos modelos complicaba aún mas las cosas. Imaginemos a aquellas personas ajenas a la elaboración del modelo que debían interpretar, por ejemplo, los diagramas de transición de estados de un proceso crítico de la empresa. Antes tenían que conocer el significado de cada elemento que formaba parte del modelo, y recién después comenzar a analizar la lógica del negocio. Esta claro que si cada uno hacia los cosas a su manera, en algún punto se iban a encontrar con una perdida de esfuerzos importante, por ejemplo, cuando se debían presentar estos modelos a un cliente o cuando un grupo externo de desarrolladores se sumaban al proyecto.

Unified Modeling Language

Unified Modeling Language

Surgió entonces la necesidad de que apareciera un lenguaje que permitiera “trabajar” a todos de la misma forma y bajo las mismas reglas. Este nuevo lenguaje tendría que proporcionar los elementos necesarios a utilizar en las distintas estapas del desarrollo del software (es decir, que no solo estuviese pensado para una etapa en particular del ciclo, sino que abarcara todas las fases).

Con todos estos objetivos en mente apareció el lenguaje UML (Unified Modeling Lenguaje). El mismo se empezó a gestar a mediados de 1994 cuando James Rambaugh se unió a la empresa Rational de Grady Booch. El primer paso en la creación de este nuevo lenguaje fue unificar dos métodos que cada uno había desarrollado: el método Booch (de Grady Booch) y OMT (de James Rambaugh). A fines de 1995 se uniría a Rational el investigador Ivar Jacobson quien aportaría muchas de sus ideas y a partir de ahí surgirían los primeros borradores de UML.

Los Tres amigos: Grady Booch, Jim Rumbaugh and Ivar Jacobson

Los Tres amigos: Grady Booch, Jim Rumbaugh and Ivar Jacobson

Además del aporte de los llamados “Tres amigos” se tomó lo mejor de otros reconocidos autores, como por ejemplo Meyer, Harol y Embley (de aquí la de-nominación de Unificado) y en 1997 se convertiría en un estandar del OMG (Object Management Group).

La unificación agrupa otros enfoques

La unificación agrupa otros enfoques

A principios de 2002 se aprobaría la versión 2.0 de UML y actualmente se encuentra la versión 2.4 fase beta (lanzada en marzo de 2011).

Pero, qué es realmente UML? Es un lenguaje de modelado visual y como todo lenguaje tiene una sintaxis y una semántica bien definida (reglas sobre como debemos elaborar e interpretar los modelos que generamos). Recordemos que un modelo es una simplificación de la realidad y el objetivo del modelado de un sistema es capturar sus partes ecesenciales (realizando una abstracción del dominio del “problema” y plasmandolo de forma gráfica).

UML además nos permite trabajar con diferentes diagramas en diferentes etapas del desarrollo de un sistema. Por ejemplo en la etapa de análisis podríamos utilizar un Diagrama de Caso de Usos, en la de diseño un Diagrama de Clases y en la etapa de implementación el Diagrama de Despliegue.

En este post vamos nos vamos a enfocar en el Diagrama de Clases y las herramientas que nos provee Visual Studio 2010 para trabajar con UML (esta por demás decir que VS nos permite trabajar con distintos diagramas como veremos en un momento). Cabe destacar, que lamentablemente la única versión de Visual Studio 2010 que nos permite trabajar con las mismas es la Ultimate (Professional y anteriores solo nos permiten visualizar los diagramas). Más info sobre esta herramienta en la página oficial.

Ok, arranquemos!… En primer lugar, seleccionamos agregar nuevo proyecto, desde el menú Archivo o desde el acceso directo que nos brinda la aplicación en la sección de bienvenida. Una de las nuevas plantillas de proyectos que tenemos en esta versión de VS 2010 con respecto a la otras es la de poder crear Proyectos de modelado.

Proyecto de Modelado

Proyecto de Modelado

Agregando este proyecto tendremos la posibilidad de crear cualquiera de los diagramas que se ven en la siguiente imagen:

Agregando un nuevo diagrama

Agregando un nuevo diagrama

Específicamente, en este post vamos a explicar como trabajar con un Diagrama de Clases UML pero sería bueno conocer los diversos diagramas que nos brinda Microsoft Visual Studio 2010 Ultimate en caso de que los necesitemos algún día.

Una vez que creamos el diagrama de clases en la pestaña de herramientas vemos los diferentes elementos de los cuales podemos utilizar para llevar a cabo el modelo que necesitamos (Class, Interface, Enumaration, Comment, Association, Aggregation, Inheritance, entre otros).

Herramientas del diagrama

Herramientas del diagrama

Para quienes no conocen o no trabajaron con UML las clases se representan de la siguiente manera:

UML - Representación de una clase

UML - Representación de una clase

Por atributos entendemos a las características del elemento en cuestión que debemos incluír en el modelo. Por ejemplo, el nombre y el número de documento podrían ser atributos dentro de una entidad Persona.

Las operaciones serían aquellas acciones o aquel comportamiento propio del elemento (o clase) que permiten que se relacione con su entorno. Siguiendo el ejemplo, la acción comer podría ser una operación de Persona.

Por último, las responsabilidades son aclaraciones que nosotros mismos podemos incluir dentro del modelo para no olvidar particularidades propias de los elementos a modelar.

Para agregar una clase, disponemos dentro del toolbox  del elemento Class . En este elemento podemos describir atributos y operaciones, de acuerdo a lo que hayamos percibido en nuestra interpretación del sistema a modelar. En VS la representación gráfica se corresponde a lo expresado en UML: nombre de la clase alineado en la parte superior y dos recuadros por debajo, uno para indicar los Atributos y otro para indicar las Operaciones (podemos incluir las responsabilidades con el objeto Comment).

Para insertar un nuevo Atributo, debemos hacer click derecho sobre el elemento del tipo Class agregado y luego en Agregar->Attribute. Mas adelante, explicaremos como editar los atributos mediante la interfaz de VS de una manera rápida. Insertar una Operación es un proceso similiar, a diferencia de que debemos hacer clic en la opción Agregar->Operation. Las opciones que podemos modificar en la misma son las que se muestan en la siguiente imagen:

Propiedades de un atributo

Propiedades de un atributo

En cuestión de segundos podemos agregar una Operación y configurar su firma, los parámetros que recibe y la visibilidad (+ Public, Private, # Internal o ~ Package), entre otras opciones.

También podemos indicar como se relacionan nuestras clases entre si, haciendo uso de los elementos:

Association: relación entre una clase origen y otra clase destino. No es una relación fuerte ya que la vida de un objeto no depende del otro.

Relación de Asociación

Relación de Asociación

Aggregation: la clase origen hace referencia a objetos de la clase destino. El tiempo de vida de un objeto no depende del que lo contiene.

Relación de Agregación

Relación de Agregación

Composition: la clase de origen hace tiene objetos de la clase destino. A diferencia de la Aggregation, en este caso el tiempo de vida del elemento contenedor condiciona al tiempo de vida del elemento contenido.

Relación de Composición

Relación de Composición

Dependency: una clase depende de otra.

Relación de Dependencia

Relación de Dependencia

Inheritance: una clase “hereda” de otra, es decir, recibe su comportamiento, atributos y responsabilidades. En UML veremos que esto se denomina con el nombre de Generalización, pero en el ambiente de la programación esto es mas conocido como herencia.

Relación de Generalización

Relación de Generalización

Para agregar cualquiera de estos elementos debemos seleccionarlo desde el cuadro de herramientas. Primero hacemos click sobre la clase origen, y luego sobre la clase destino para indicar la relación. En la siguiente imagen podemos ver un ejemplo rápido de un diagrama de clases creado utilizando estas herramientas:

Diagrama de Clases

Diagrama de Clases

Cada elemento que incluimos en nuestro modelo tiene una gran cantidad de propiedades que podemos editar para hacer nuestro diagrama tan complejo como queramos. Por ejemplo, veamos las propiedades que nos permite editar sobre la clase Tarjeta:

Propiedades de Clase

Propiedades de Clase

Hemos visto las herramientas que nos provee Visual Studio 2010 que nos permite utilizar UML de una manera sencilla y eficiente.

Espero que les sea de utilidad!

Gracias a @mferrero por colaborar en el articulo!

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.

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!

NuGet

Nuget es un gestor de paquetes Open Source que viene integrado con Visual Studio y que permite a los desarrolladores buscar, descargar, instalar, configurar y actualizar librerías en nuestros proyectos .NET de una manera limpia y transpartente.

Nuget

Nuget

Esta herramienta nos evita tener que, por cada compenete externo que querramos utilizar, buscar y descargar de la web los assemblies de la versión que estemos necesitando, instalarlos o copiarlos en nuestro equipo, agregar las referencias, probar que funcione y rezar para que esta no tenga dependencias a otras líbrerias que no tengamos (no les resulta familiar esta secuencia de pasos?).

Es importante destacar que Nuget esta disponible para todas las versiones de Visual Studio 2010, pero no para versiones anteriores del IDE.

Vamos a ver un ejemplo sencillo agregando a nuestro proyecto ASP.NET MVC3 un paquete de librerias que nos permita integrar twitter. Tenemos dos formas de instalar nuestros paquetes con Nuget, utilizando la interfaz gráfica o la consola.

Veamos la primer opción, para eso vamos a la carpeta Reference, hacemos click derecho sobre la misma y elegimos la opción “Add Library Package Reference“. Esto nos va a abrir la siguiente interfaz:

Interfaz gráfica de Nuget

Interfaz gráfica de Nuget

Ahora hacemos click en la pestaña “Online” y procedemos a buscar librerías relacionadas a twitter. Del listado de componentes encontrados vamos a instalar Twitter Helper, componente que nos permite agregar widgets de twitter de una manera muy sencilla. Por lo tanto seleccionamos el paquete y hacemos click en el botón “Install”:

Instalando nuestro primer paquete con Nuget

Instalando nuestro primer paquete con Nuget

Instalado el componente, vamos a hacer una simple prueba utilizando algunos de los widgets del helper sobre una vista de nuestro proyecto. En este caso vamos a mostrar una caja de busqueda por el hashtag “Nuget” y para eso vamos a escribir lo siguiente:

1: <h2> @ViewBag.Message</h2>
2: <p>
3:  To learn more about ASP.NET MVC...
4:   @TwitterGoodies.Search("Nuget")
5: </p>

Ejecutamos y veremos el widget en acción!

Widget en acción!

Widget en acción!

Simple, no? 🙂

Bien, la otra alternativa para usar Nuget es por medio de la consola integrada a Visual Studio. La misma la podremos abrir desde menu “Tools\Library Package Maneger\Package Manager Console“.

Desde la consola podremos instalar nuestros paquetes escribiendo el siguiente comando “PM > Install-Package Twitter.Helper”. En nuestro caso nos mostrara un mensaje de advertencia ya que hemos instalado el paquete previamente.

Instalando nuestro paquete desde la consola

Instalando nuestro paquete desde la consola

Ademas de esta línea de comando tenemos a disposición muchas otras, como por ejemplo para la busqueda de paquetes.

Espero que les sea de utilidad!

Visual Studio 2010 SP1

Ya está disponible para descargar el primer Service Pack de Visual Studio 2010.

Visual Studio 2010

Visual Studio 2010

Tenemos dos alternativas para la descarga:

  • Utilizando Microsoft Web Platform Installer del cual ya hemos hablado en otras entradas y que podemos descargar desde aquí (tamaño aproximado 800 kb y la instalación es on-line). Instala las características mínimas necesarias para la versión de VS2010 que tengamos instalado.
  • Descargando la imagen ISO (tamaño aproximado 1.5GB) que nos permitirá instalar el SP1 sobre cualquier versión de VS2010 y podremos personalizar las características a instalar. Descargar desde aquí.

En el primer link podremos encontrar información sobre las características que trae el SP.

Monodroid: Android en .NET

Monodroid es un SDK (software development kit) que nos permite desarrollar aplicaciones Android bajo un entorno .NET, y nos provee un plugin para que podemos trabajar con Visual Studio 2010 como IDE (actualmente solo con C# como lenguaje).

En este post vamos a explicar los pasos necesarios para preparar el entorno de desarrollo de Monodroid en Visual Studio 2010.

Primer Paso: Instalando el SDK de Java

Lo primero que debemos hacer es descargar e instalar el SDK de Java desde aquí (archivo jdk-6u24-windows-i586.exe). Para aquellos que aún no lo sepan las aplicaciones Android están desarrolladas sobre Java, por lo que es preciso tener instalado dicho entorno para correr el emulador y nuestras app.

Descargando el SDK de Java

Descargando el SDK de Java

Segundo Paso: Instalando el SDK de Android

Deberemos bajar el instalador del SDK desde aquí (archivo installer_r10-windows.exe). Descargado el instalador, ejecutamos el mismo y finalizada la instalación ejecutamos el SDK Manager desde el cual vamos a descargar e instalar los siguientes paquetes:

  • Android SDK Tools, revision 10
  • Android SDK Platform-tools, revision 3

También deberemos instalar las SDK Platforms que prefiramos, como por ejemplo la de la versión 2.2 de Android:

  • SDK Platform Android 2.2, API 8, revision 2
Instalación del SDK de Android

Instalación del SDK de Android

Tercer Paso: Configurando el emulador

Es hora de configurar nuestro emulador, el mismo será utilizado por Visual Studio 2010 para ejecutar nuestras aplicaciones Android. Para ello ejecutamos nuevamente el SDK Manager y nos dirigimos a la opción “Virtual Devices“.

Visualizando los emuladores creados.

Visualizando los emuladores creados.

Por defecto deberíamos tener definidos dos dispositivos, uno para la versión 2.1 y otro para la 2.2. Sin embargo podemos definir nuevos dispositivos haciendo click en el botón “New…“. Al crear un nuevo dispositivo virtual podremos definir la versión en que va a correr el mismo (esto va a depender de las SDK Platform que hayamos instalado previamente), el tamaño disponible para la SD Card, resolución de la pantalla y hardware sobre el que va a correr.

Cuarto Paso: Instalando el plugin de Monodroid para Visual Studio 2010

Bien, llegamos al último paso, para ello vamos a descargar el plugin desde aquí (archivo monodroid9639.msi). Es importante que antes de comenzar la instalación no tengamos abierto VS2010.

Instalación Plugin Monodroid

Instalación Plugin Monodroid

Finalizada la instalación vamos a abrir Visual Studio 2010 y a crear un nuevo proyecto. Para ello vamos a “File\New\Project…” y en la ventana que se nos abre vamos a seleccionar el nuevo template de proyectos Visual C# – Monodroid. Hecho esto veremos tres tipos de proyectos, para el ejemplo vamos a crear una aplicación Monodroid Application:

Creando nuestra primer aplicación Monodroid

Creando nuestra primer aplicación Monodroid

Ahora simplemente vamos a ejecutar la aplicación, veremos que se nos va a presentar una ventana que nos pedirá que selecciones un disposivo (la lista va a aparece vacía debido a que aún no tenemos un emulador corriendo). Para levantarlo vamos hacer click en “Start Emulation Image“:

Seleccionando el emulador

Seleccionando el emulador

Ahora nos aparecerá una lista con los dispositivos virtuales que hayamos definido al momento de configurar los emuladores durante la instalación (ver paso 3). Elegimos la versión que vamos a utilizar y aceptamos.

Lista de emuladores

Lista de emuladores

Cuando seleccionamos la versión que vamos a utilizar y pulsamos “OK” veremos que se va a abrir el emulador. También vamos a ver que ya tenemos un dispositivo disponible en donde podemos instalar y correr nuestra app:

Listado de dispositvos

Listado de dispositvos

Antes de ejecutar nuestra aplicación debemos esperar a que el emulador bootee. Levantado Android en el dispositivo hacemos “OK” en la ventana emergente para que se instale nuestra aplicación. Veremos que antes de que se ejecute nuestra app se instalara en el emulador el entorno de Monodroid necesario para correr la app:

Instalando Monodroid en el emulador

Instalando Monodroid en el emulador

Terminado de instalarse el entorno Monodroid en el emulador podremos probar nuestra app:

Nuestra primer aplicación Android!

Nuestra primer aplicación Android!

Es importante que si vamos a utilizar el emulador de Android 2.2 (o cualquier otra versión) en las propiedades del proyecto tengamos dicha versión definida.

Mas información detalla de la instalación la pueden encontrar aquí.