Para quien esté interesado en Django y lo que gira alrededor de este, os dejo la URL:

PyBlog

Esto no quiere decir que abandone este blog, pero al menos en corto / medio plazo estaré mas enfocado a Django.

Un saludo.

Pues cambia de servidor, que te están timando cojones.

Venga no, que quizá tenga otras cualidades.

¿Qué podemos hacer?

Visual Studio 2010 SP1 (importante que sea el SP1) tiene una opción que sirve para añadir los .DLL necesarios para poder ejecutar nuestras aplicaciones que usen tanto ASP.NET MVC como SQL SERVER CE 4:

Como véis, está en el menú Project o Proyecto en la versión en castellano.

Si hacemos click:

Nos da para marcar 3 opciones:

ASP.NET MVC: Sirve, como bien dice el nombre, para copiar las .DLL necesarias para poder ejecutar ASP.NET MVC
ASP.NET Web Pages and Razor syntax: Tenemos que marcar esta opción si usamos el motor Razor en nuestras aplicaciones (Razor++)
SQL Server Compact: Por último con esta opción coopiamos un montón de .DLL para poder usar bases de datos en nuestras aplicaciones.

Y nada más. Desplegamos la aplicación a nuestro servidor y todo funcionará de maravilla.

Un saludo.

En el <div> donde vamos a embeber nuestra aplicación, en el parámetro source, hacemos lo siguiente:

<param name="source" value="@Url.Content("~/ClientBin/PruebaWCF.SL.xap")?1"/>

2 cosas:

Estamos dandole la URL de nuestro .xap usando un helper de ASP.NET MVC, así cuando hagamos deploy, podrá saber dónde se encuentra el fichero.

Por otro lado, fijaros en el ?1, le pasamos por parámetro un valor totalmente arbitrario, con eso invalidamos el caché y hará que cargue el .xap de nuevo.

Una mejora de este truco es hacerlo automáticamente (pues tendríamos que cambiar el parámetro en cada build)

<param name="source" value="@Url.Content("~/ClientBin/PruebaWCF.SL.xap")?@DateTime.Now.ToLongTimeString()"/>

Así pues generaremos una cadena nueva cada vez que compilemos.

Podemos cambiarlo y llevar la cuenta de cuantos “builds” hemos hecho creando una simple clase. Pero vaya, con esto va de sobra para que la cosa funcione como debería de funcionar sin tocar nada…

Hasta otra (espero que pronto )

Espero adquirir pronto más conocimiento para ir subiendo mis aplicaciones (ya tengo un par de ideas, aunque más son siempre bienvenidas ).

También espero coger ideas para ir escribiendo algunos artículos para todos vosotors (aquí tambien son bienvenidas las ideas )

Así que nada, espero pronto traeros sorpresas

Un saludo.

En este post vamos a hablar sobre una de esas cosas nuevas, en concreto de la actualización de las herramientas de ASP.NET MVC 3. Las podéis bajar de aquí.

¿Qué trae de nuevo? Vamos paso por paso.

Vamos a Visual Studio y le damos a crear una nueva ASP.NET MVC 3 Web Application

Como véis, tenemos una nueva opción, Intranet Application. Como su nombre indica, este tipo de aplicaciones están pensadas para funcionar en intranet, así que el sistema de autentificación será Windows Authentication en vez de Forms Authentication (Por lo cual se quitará el AccountController). Por lo demás es igual a Internet Application.

Si os seguís fijando, ahora ASP.NET MVC 3, tiene soporte HTML 5, lo cual es muy interesante. Vamos a crear una Internet Application con la opción de HTML 5 marcada.

Si váis al archivo _Layout.cshtml os podréis fijar que está usando los nuevos tags de HTML 5. Y no solo eso, además ahora las nuevas herramientas trae por defecto Modernizr que para quien no lo sepa es una librería en javascript que nos ayuda a usar las nuevas tecnologías como HTML 5 y CSS 3 a la vez que mantenemos compatibilidad con navegadores más antiguos.

Aparte de Modernizr, ahora disponemos de Jquery 1.5 y no es eso lo más interesante, ahora estas librerías vienen como paquetes de NuGet lo que significa que cuando salga por ejemplo una nueva versión de jQuery o Modernizr, se actualizará en nuestra aplicación usando NuGet los que nos ahorra de quebraderos de cabeza (aunque por lado negativo, no actualiza las referencias en el Layout, aunque era previsible).

Ahora ASP.NET MVC 3 trae por defecto Entity Framework 4.1 lo cual nos ahorra un poco de tiempo

¿Ejecutamos la aplicación? Venga:

¡Ahora el Layout usa HTML5! Bordes redondeados, título con sombra… mooola

Ahora vamos con la última actualización, scaffolding. ¿Qué es eso? Scaffolding sirve para generar código que nos permita crear, leer, actualizar y borrar entradas en una base de datos, vaya, nos genera código CRUD. Quizás te hayas dado cuenta que ya podíamos generar código para una de estas cosas cuando creabamos una vista, pero ahora podemos generar directamente un controlador con el código necesario para hacer todas estas cosas con sus respectivas vistas y todo.

¿Vemos como funciona esta mágia?

Vamos a crear una clase, algo simple:

namespace MVC3Update.Models
{
    public class Persona
    {
        public int ID { get; set; }
        public string Nombre { get; set; }
        public int Edad { get; set; }
        public string Email { get; set; }
    }
}

Aquí la tan socorrida clase persona

¿Qué vamos a usar de base de datos? ¿SQL Server CE 4? Pues vamos a instalarlo con NuGet:

PM> install-package EntityFramework.SqlServerCompact

Compilamos la aplicación y vamos ahora con el controlador:

Uh uh, opciones nuevas. Aquí le decimos que queremos un controlador con las acciones para leer/escribir, sus respectivas vistas y esto usando EntityFramework. Además especificamos la clase con la que trabajará y en la clase para contexto le damos a añadir una nueva, le ponemos PersonasContext y la creará por nosotros.

Antes de ver los detalles, vamos a ejecutar la aplicación y nos vamos al controlador Personas, nos aparecerá el listado:

Clicamos en crear nuevo y nos aparece una vista para crear nueva Persona

Metemos algunos datos, le damos a añadir y ¡Voila!, los datos están añadidos:

¿Una maravilla verdad? Puedes incluso ver que la base de datos se ha creado y tal.

Si le echamos un ojo al controlador, vemos que nos ha creado todo el CRUD y con todo el código necesario para funcionar:

using System;
using System.Collections.Generic;
using System.Data;
using System.Data.Entity;
using System.Linq;
using System.Web;
using System.Web.Mvc;
using MVC3Update.Models;

namespace MVC3Update.Controllers
{
    public class PersonasController : Controller
    {
        private PersonasContext db = new PersonasContext();

        //
        // GET: /Personas/

        public ViewResult Index()
        {
            return View(db.Personas.ToList());
        }

        //
        // GET: /Personas/Details/5

        public ViewResult Details(int id)
        {
            Persona persona = db.Personas.Find(id);
            return View(persona);
        }

        //
        // GET: /Personas/Create

        public ActionResult Create()
        {
            return View();
        } 

        //
        // POST: /Personas/Create

        [HttpPost]
        public ActionResult Create(Persona persona)
        {
            if (ModelState.IsValid)
            {
                db.Personas.Add(persona);
                db.SaveChanges();
                return RedirectToAction("Index");
            }

            return View(persona);
        }

        //
        // GET: /Personas/Edit/5

        public ActionResult Edit(int id)
        {
            Persona persona = db.Personas.Find(id);
            return View(persona);
        }

        //
        // POST: /Personas/Edit/5

        [HttpPost]
        public ActionResult Edit(Persona persona)
        {
            if (ModelState.IsValid)
            {
                db.Entry(persona).State = EntityState.Modified;
                db.SaveChanges();
                return RedirectToAction("Index");
            }
            return View(persona);
        }

        //
        // GET: /Personas/Delete/5

        public ActionResult Delete(int id)
        {
            Persona persona = db.Personas.Find(id);
            return View(persona);
        }

        //
        // POST: /Personas/Delete/5

        [HttpPost, ActionName("Delete")]
        public ActionResult DeleteConfirmed(int id)
        {
            Persona persona = db.Personas.Find(id);
            db.Personas.Remove(persona);
            db.SaveChanges();
            return RedirectToAction("Index");
        }

        protected override void Dispose(bool disposing)
        {
            db.Dispose();
            base.Dispose(disposing);
        }
    }
}

No le falta detalle, pero ninguno ninguno.

No solo nos ha generado ese código, también nos ha creado las vistas con el código necesario para trabajar y todo:

Por si fuera poco, podemos instalar algún paquete NuGet para ampliar las posibilidades de scaffolding a la hora de crear un controlador. Por ejemplo, podemos instalar el maravilloso MvcScaffolding que tiene muchísimas más opciones, es personalizable, nos permite crear nuestros propios plugins… Por defecto podemos generar un controlador con CRUD contra un EntityFramework e incluso generar un controlador que usará un repositorio el cual generará también por supuesto. Si trabajamos con NHibernate por ejemplo podremos crear un plugin que genere código contra NHibernate o lo que queramos vaya…

En resumen, la actualización de las herramientas de ASP.NET MVC 3 nos trae:

• Soporte para crear aplicaciones para intranet
• La posibilidad de usar HTML5 en nuestras aplicaciones
• Trae por defecto jQuery 1.5.1 y Modernizr, ambos como paquetes de NuGet
• El dialogo de crear controlador ha sido ampliado para soportar scaffolding
• Podemos usar nuestra propia librería de scaffolding en el anteriormente citado diálogo
• Entity Framework 4.1 incluido de serie

Una simple actualización, y qué de maravillas…

Hasta otra

Ésta vez vamos a usar como ejemplo ASP.NET MVC 3. Ésta vez vamos a usar otra librería, en este caso vamos a probar con Ninject.

Ninject es una de las muchas alternativas que hay para implementar Dependency Injection y para mi gusto es de las mejores para ASP.NET MVC.

Vamos a empezar creando la aplicación, la llamaremos MVCWithDI, crearemos una Aplicacion de internet pues ya nos ofrece un Layout básico.

Implementaremos la misma idea que en el artículo anterior:

Creamos una clase llamada Persona:

namespace MVCWithDI.Models
{
    public class Persona
    {
        public string Nombre { get; set; }
        public int Edad { get; set; }
    }
}

Y ahora creamos las interfaces de los servicios que vamos a usar:

namespace MVCWithDI.Abstract
{
    public interface IFechaAEdad
    {
        int Conversion(string fecha);
    }
}

namespace MVCWithDI.Abstract
{
    public interface ICapitalizador
    {
        string Capitalizar(string nombre);
    }
}

Ahora implementamos estos servicios:

using System;
using MVCWithDI.Abstract;

namespace MVCWithDI.Concrete
{
    public class FechaAEdad : IFechaAEdad
    {
        public int Conversion(string fecha)
        {
            int edad;
            var partesfecha = fecha.Split('/');

            // Añadimos el año
            edad = DateTime.Now.Year - Int32.Parse(partesfecha[2]);

            // Comprobamos si hemos cumplido ya este año o no
            if (Int32.Parse(partesfecha[1]) < DateTime.Now.Month) // todavia no hemos cumplido
                edad -= 1; // le restamos un año pues
            if (Int32.Parse(partesfecha[1]) == DateTime.Now.Month)
                if (Int32.Parse(partesfecha[0]) > DateTime.Now.Day) // no ha llegado el dia
                    edad -= 1;

            return edad;
        }
    }
}

using MVCWithDI.Abstract;

namespace MVCWithDI.Concrete
{
    public class Capitalizador : ICapitalizador
    {
        public string Capitalizar(string nombre)
        {
            string nombreCapitalizado = string.Empty;

            var trozoNombre = nombre.Split();

            foreach (var trozo in trozoNombre)
            {
                nombreCapitalizado += char.ToUpper(trozo[0]) + trozo.Substring(1) + " ";
            }

            return nombreCapitalizado.TrimEnd();
        }
    }
}

Ya tenemos los servicios implementados.

Vamos a crear un constructor en el controlador Home y agregar unas referencias:

private readonly IFechaAEdad _fechaAEdad;
private readonly ICapitalizador _capitalizador;

public HomeController(IFechaAEdad fechaAEdad, ICapitalizador capitalizador)
{
	_fechaAEdad = fechaAEdad;
	_capitalizador = capitalizador;
}

Simplemente el constructor recibe un par de referencias de los servicios que usará, al igual que se hizo con el ViewModel en WPF

Ahora vamos a actualizar el método Index:

public ActionResult Index()
{
return View();
}

Simplemente muestra la vista. Vamos a editar ahora la vista (viene creada con el proyecto):

@{
    ViewBag.Title = "ASP.NET MVC 3 con Ninject";
}

@using (Html.BeginForm())
{
    @Html.Label("Nombre y Apellido")
    @Html.TextBox("nombre")
    @Html.Label("Fecha de nacimiento (dd/mm/yyyy)")
    @Html.TextBox("fecha")
    <input type="submit" value="Dale" />
}

Un simple formulario para recoger los datos. Este formulario hará POST en la misma acción Index así que vamos a crear una acción Index solo para peticiones POST que maneje los datos del formulario:

[HttpPost]
public ActionResult Index(string nombre, string fecha)
{
	var persona = new Persona
						{
							Nombre = _capitalizador.Capitalizar(nombre),
							Edad = _fechaAEdad.Conversion(fecha)
						};
	return RedirectToAction("MostrarPersona", persona);
}

Algo simple, del formulario recibe esos dos parametros, los pasamos a sus respectivos servicios y creamos un objeto Persona con esa información.

Ésta acción nos redirige a otra acción, en este caso una llamada MostrarPersona, al cual le pasamos el objeto creado:

public ActionResult MostrarPersona(Persona persona)
{
	return View(persona);
}

Ésta acción simplemente nos muestra una vista a la cual le pasamos el objeto persona.

Bien, vamos a crear esta vista, las opciones quedarán así:

Al poner lo de Details ya nos creará una vista en la cual nos mostrará los datos de la persona, justo lo que necesitamos.

Ya tenemos la aplicación implementada. Ahora necesitamos implementar el Dependency Injection para que funcione.

ASP.NET MVC 3 soporta Dependency Injection sin tener que hacer malabares ni nada extra, ya que antiguamente necesitabamos implementar muchas cosas por nuestra cuenta.

Ahora, simplemente tendremos que implementar IDependencyResolver y pasar esa implementación al framework, veremos como:

Para empezar, necesitamos Ninject bien lo bajas de su web o más comodamente usamos NuGet

PM> install-package Ninject

Ya que tenemos Ninject, vamos a implementar IDependencyResolver:

using System;
using System.Collections.Generic;
using System.Web.Mvc;
using Ninject;

namespace MVCWithDI.Infrastructure
{
    public class NinjectDependencyResolver : IDependencyResolver
    {
        private readonly IKernel _kernel;

        public NinjectDependencyResolver(IKernel kernel)
        {
            _kernel = kernel;
        }

        public object GetService(Type serviceType)
        {
            return _kernel.TryGet(serviceType);
        }

        public IEnumerable<object> GetServices(Type serviceType)
        {
            return _kernel.GetAll(serviceType);
        }
    }
}

IDependencyResolver tiene dos métodos. Con GetService devolvemos el servicio que necesitamos y con GetServices recogemos una colección de dicho servicio.

Nuestra implementación recibe una instancia de IKernel. En Ninject el IKernel es nuestro contenedor, en el cual iremos enlanzado nuestros servicios.

Vale, entonces necesitamos crear dicho contenedor y enlazar nuestros servicios, así que vamos a ello:

using System.Web.Mvc;
using MVCWithDI.Abstract;
using MVCWithDI.Concrete;
using Ninject;

namespace MVCWithDI.Infrastructure
{
    public class NinjectKernelSetup
    {
        public static void Setup()
        {
            var kernel = new StandardKernel();

            kernel.Bind<ICapitalizador>().To<Capitalizador>();
            kernel.Bind<IFechaAEdad>().To<FechaAEdad>();

            DependencyResolver.SetResolver(new NinjectDependencyResolver(kernel));
        }
    }
}

No es nada complicado, ni explicación requiere. A excepción de la última linea. Ahí es donde le decimos al framework que nuestro sistema de Dependency Injection va a ser manejado por Ninject (pasandole la clase que creamos implementando IDependencyResolver).

Por último, necesitamos unir este código con nuestra aplicación, para ello nos vamos al fichero Global.asax.cs y en el método Application_Start insertamos una nueva linea:

protected void Application_Start()
{
	AreaRegistration.RegisterAllAreas();

	RegisterGlobalFilters(GlobalFilters.Filters);
	RegisterRoutes(RouteTable.Routes);

	NinjectKernelSetup.Setup();
}

Ahora ejecutamos la aplicación, insertamos nuestros datos y el resultado será similar a este:

¿Fácil verdad?

Ahora bien… ¿Como implementamos eso en WPF y MVVM Light?

Faacil faacil. Para este ejemplo vamos a usar Unity que es una de las muchas librerías para Dependency Injection.

Vamos a ello:

Creamos una nueva aplicación usando la plantilla de MVVM Light, la llamaremos MVVMWithDI.

Vamos a cambiar nuestra ventana MainWindow.xaml por algo simple creado rápidamente en Blend:

<Window
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        xmlns:d="http://schemas.microsoft.com/expression/blend/2008" xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006" mc:Ignorable="d" x:Class="MVVMWithDI.MainWindow"
        Title="MVVM Con DI"
        Height="304"
        Width="260"
        Background="#FFDAFEFF">

	<Window.DataContext>
		<Binding Path="Main" Source="{StaticResource Locator}"/>
	</Window.DataContext>

    <Grid x:Name="LayoutRoot">

        <Label Content="Nombre y apellido:" HorizontalAlignment="Left" Margin="8,24,0,0" VerticalAlignment="Top"/>
        <TextBox Height="26.04" Margin="8,53.96,19,0" TextWrapping="Wrap" VerticalAlignment="Top" Text="{Binding Nombre}"/>
        <Label Content="Fecha nacimiento (dd/mm/yyyy):" Margin="8,89,46,0" VerticalAlignment="Top" d:LayoutOverrides="Width"/>
        <TextBox Margin="8,118.96,19,121" TextWrapping="Wrap" Text="{Binding FechaNacimiento}"/>
        <Button Content="Dale" Height="28" Margin="0,0,19,83.942" VerticalAlignment="Bottom" HorizontalAlignment="Right" Width="69" Command="{Binding DaleCommand}"/>
        <TextBlock Margin="8,0,19,12" TextWrapping="Wrap" VerticalAlignment="Bottom" Height="39" FontWeight="Bold" Foreground="#FF0048D6" Text="{Binding Saludo}"/>

    </Grid>
</Window>

Nada complejo, lo justo y necesario para implementar Dependency Injection.

Empezamos con una clase Persona que aloje nuestro objeto:

namespace MVVMWithDI.Model
{
    public class Persona
    {
        public string Nombre { get; set; }
        public int Edad { get; set; }
    }
}

Ahora necesitaremos 2 servicios, uno que nos pase de “Fecha nacimiento => Edad” y otro que nos capitalice el nombre.

Como ya sabéis, todos los servicios que creemos serán interfaces, las cuales serán luego implementadas por los servicios concretos.

El conversor:

namespace MVVMWithDI.Abstract
{
    public interface IFechaAEdad
    {
        int Conversion(string fecha);
    }
}

El “capitalizador”

namespace MVVMWithDI.Abstract
{
    public interface ICapitalizador
    {
        string Capitalizar(string nombre);
    }
}

Vale, ya tenemos las interfaces, vamos con las implementaciones de esos servicios:

namespace MVVMWithDI.Concrete
{
    public class FechaAEdad : IFechaAEdad
    {
        public int Conversion(string fecha)
        {
            int edad;
            var partesfecha = fecha.Split('/');

            // Añadimos el año
            edad = DateTime.Now.Year - Int32.Parse(partesfecha[2]);

            // Comprobamos si hemos cumplido ya este año o no
            if (Int32.Parse(partesfecha[1]) < DateTime.Now.Month) // todavia no hemos cumplido
                edad -= 1; // le restamos un año pues
            if (Int32.Parse(partesfecha[1]) == DateTime.Now.Month)
                if (Int32.Parse(partesfecha[0]) > DateTime.Now.Day) // no ha llegado el dia
                    edad -= 1;

            return edad;
        }
    }
}

Algo simple, no vamos a marearnos en comprobar la entrada para simplificar el artículo.

Vamos con la implementación de la clase que capitaliza

namespace MVVMWithDI.Concrete
{
    public class Capitalizador : ICapitalizador
    {
        public string Capitalizar(string nombre)
        {
            string nombreCapitalizado = string.Empty;

            var trozoNombre = nombre.Split();

            foreach (var trozo in trozoNombre)
            {
                nombreCapitalizado += char.ToUpper(trozo[0]) + trozo.Substring(1) + " ";
            }

            return nombreCapitalizado.TrimEnd();
        }
    }
}

Otra clase simple.

Ahora toca implementar el MainViewModel

Empecemos con este código:

public class MainViewModel : ViewModelBase
{
	private readonly IFechaAEdad _fechaAEdad;
	private readonly ICapitalizador _capitalizador;

	public MainViewModel(IFechaAEdad fechaAEdad, ICapitalizador capitalizador)
	{
		_fechaAEdad = fechaAEdad;
		_capitalizador = capitalizador;
	}
}

Si recordás el artículo anterior, si un ViewModel (y cualquier clase en verdad) va a hacer uso de algún servicio, tenemos que crear un constructor el cual reciba las implementaciones de dichos servicios y lo indicamos colocando las interfaces que dichos servicios han de implementar. Nada dificil.

͉ste sería el código del viewModel completo:

    public class MainViewModel : ViewModelBase
    {
        private readonly IFechaAEdad _fechaAEdad;
        private readonly ICapitalizador _capitalizador;
        private string _nombre;
        private string _fechaNacimiento;
        private string _saludo;

        public RelayCommand DaleCommand { get; set; }

        public MainViewModel(IFechaAEdad fechaAEdad, ICapitalizador capitalizador)
        {
            _fechaAEdad = fechaAEdad;
            _capitalizador = capitalizador;

            DaleCommand = new RelayCommand(Dale);
        }

        public string Nombre
        {
            get { return _nombre; }
            set
            {
                _nombre = value;
                RaisePropertyChanged("Nombre");
            }
        }

        public string FechaNacimiento
        {
            get { return _fechaNacimiento; }
            set
            {
                _fechaNacimiento = value;
                RaisePropertyChanged("FechaNacimiento");
            }
        }

        public string Saludo
        {
            get { return _saludo; }
            set
            {
                _saludo = value;
                RaisePropertyChanged("Saludo");
            }
        }

        private void Dale()
        {
            var nombre = _capitalizador.Capitalizar(Nombre);
            var edad = _fechaAEdad.Conversion(FechaNacimiento);

            var persona = new Persona
                              {
                                  Nombre = nombre,
                                  Edad = edad
                              };
            Saludo = string.Format("Hola soy {0} y tengo {1} años", persona.Nombre, persona.Edad);
        }
    }
}

Fijaros como Dale hace uso de los servicios pero en ningun momento está el ViewModel acoplado a ninguno de esos dos servicios.

Si intentaramos compilar ahora el programa obtendríamos un error:

'MVVMWithDI.ViewModel.MainViewModel'

Normal… el ViewModelLocator está creando las instancias de los ViewModel sin proporcionar ningún argumento… Entonces, ¿Qué necesitamos? Necesitamos un contenedor que nos provea de las implementaciones que el ViewModel (o cualquier clase) nos pida. Para este programa vamos a usar Unity y como siempre usaremos NuGet para ello:

install-package Unity

Vale, ya tenemos Unity, ahora lo que necesitamos crear es una clase que comunmente se suele nombrar Bootstrapper y colocar ahí todo el código que necesitamos para echar a andar Unity:

namespace MVVMWithDI
{
    public class Bootstrapper
    {
        public IUnityContainer Container { get; set; }

        public Bootstrapper()
        {
            Container = new UnityContainer();

            ConfigureContainer();
        }

        private void ConfigureContainer()
        {
            Container.RegisterType<IFechaAEdad, FechaAEdad>();
            Container.RegisterInstance<ICapitalizador>(new Capitalizador());
            Container.RegisterType<MainViewModel>();
        }
    }
}

Una clase muy sencillita. Creamos un objeto del tipo IUnityContainer que para que nos entendamos, es el alma de la fiesta aquí. El contenedor es donde registramos todas las interfaces con sus respectivas implementaciones o simplemente registramos una clase que use servicios para que la autoresuelva el contenedor por si solo.

Por pasos:

Podemos registrar tipos usando RegisterType como véis con el caso de IFechaAEdad. Simplemente le indicamos la interfaz y la implementación concreta a usar.
También podemos registrar una instancia en vez del tipo directamente, como en el caso de ICapitalizador que estamos registrando una instancia en vez del tipo en sí. Esto es útil cuando el tipo tiene un constructor con parámetros, así podemos crear la instancia de antemano y luego meterla en el contenedor. En este caso sería mejor usar la otra forma, pero aquí estamos para enseñar maneras
Por último, podemos registrar directamente un tipo, en este caso estamos registrando el ViewModel. Lo hacemos por comodidad, pues si no lo hicieramos tendriamos que, por cada parámetro que recibe dicho ViewModel llamar al contenedor y decirle que nos provea de una implementación de dicho parámetro.

Vale, ya tenemos Unity funcionando bien, ahora solo necesitamos un sitio donde podamos instanciar el Bootstrapper, en este caso nos va bien en el ViewModelLocator.

Para empezar vamos a borrar la clase entera y vamos a reimplementarla de una manera más sencilla:

public class ViewModelLocator
{
	private static Bootstrapper _bootStrapper;

	static ViewModelLocator()
	{
		if (_bootStrapper == null)
			_bootStrapper = new Bootstrapper();
	}

	public MainViewModel Main
	{
		get { return _bootStrapper.Container.Resolve<MainViewModel>(); }
	}
}

Mucho más simple, ¿Verdad? Aquí estamos instanciando el Bootstrapper en el constructor, y cada vez que pidamos el MainViewModel, el contenedor de Unity lo resolverá y eso incluye los servicios que necesita para funcionar.

Por último tenemos que borrar una linea de MainWindow.xaml.cs:

Closing += (s, e) => ViewModelLocator.Cleanup();

La eliminamos pues ya no estamos haciendo uso de ese método del ViewModelLocator

Pues nada, ya está, en resumen:

Creamos las interfaces de nuestros servicios, las implementaciones de dichos servicios.
Si una clase va a usar esos servicios, pasamos las interfaces como parámetros en el constructor.
Registramos todos los servicios en el contenedor de nuestra libreria de elección.
Finalmente ejecutamos el motor de Unity para que todo funcione.

Si mañana decidimos por ejemplo cambiar la clase que capitaliza los nombres por una más avanzada (no sé, que compruebe los nombres en una base de datos y añada también tildes si hace falta) solo tendremos que ir al contenedor de Unity y cambiar la implementación de ICapitalizador por la nueva clase que hemos creado. Todo seguirá funcionando perfectamente sin tener que cambiar ninguna linea de codigo más.

Aquí te dejo el código fuente.

Hasta otra.

¿Por qué? ¿Por qué es bueno usar Dependency Injection en mi aplicación?

Vamos a poner un ejemplo imaginario de una clase:

public class MiClase
{
	private MiRepositorio _repo;
	private UnServicio _servicio;

	public Cliente ManejarCliente(int id)
	{
		_repo = new MiRepositorio();
		_servicio = new UnServicio();

		var cliente = _repo.BuscarCliente(id);
		cliente.Tipo = _servicio.AsignarTipoCliente();

		return cliente;
	}
}

Una clase como otra cualquiera… Tiene un método que devuelve un cliente dado un id. Ese cliente lo sacamos de un repositorio y luego le asignamos un Tipo de cliente usando un servicio pensado para ello.

¿Fácil verdad? Es un trozo de código para nada anormal.

Ahora bien, ¿Recordás vuestras clases sobre Programación orientada a objetos? ¿Qué decian? Ah si, que las clases tienen que estar lo más desacopladas posibles entre si.

En este caso, la clase MiClase está acoplada con 2 clases más: MiRepositorio y UnServicio y ya sabemos qué conlleva eso…. Si algún dia queremos cambiar el servicio o el repositorio para pasar de una base de datos a algo más sencillito como un xml, pues tendríamos que ir cambiando las referencias en mil lados.

No solo está ahí el problema… ¿Qué pasaría si quisieramos hacer Unit Test? Pues lloraríamos directamente… ¿Cómo se supone que voy a testear ManejarCliente? La idea está en poder testear componentes de manera aislada, y testear este método implica el uso del repositorio y del servicio. Esto ya arruina el testeo, no solo eso, el repositorio necesita hablar con una base de datos real y si en este caso estamos extrayendo un cliente de dicha base de datos, pues vamos a necesitar un cliente con el que poder jugar en el testeo y que luego no joda la aplicación… Lo suyo sería poder usar una repositorio de mentira en el testeo y así ahorrarnos problemas. Bueno, esto da para un artículo, así que lo dejamos para otro día.

Bueno vale, tenemos una clase muy acoplada con otras, que apenas se puede testear decentemente, que nos haría cambiar mucho código si algún día cambiara los servicios o los repositorios… Vamos, esto no es mantenible ni por asomo.

¿Cómo lo solucionamos? Tal y como piensas… Con Dependency Injection. Gracias a este patrón podemos librarnos de todos esos problemas de una forma muuuy sencilla.

Vamos a ver como se vería nuestra clase si implementaros Dependency Injection en ella:

public class MiClase
{
	private IMiRepositorio _repo;
	private IUnServicio _servicio;

	public MiClase(IMiRepositorio repositorio, IUnServicio servicio)
	{
		_repo = repositorio;
		_servicio = servicio;
	}

	public Cliente ManejarCliente(int id)
	{
		var cliente = _repo.BuscarCliente(id);
		cliente.Tipo = _servicio.AsignarTipoCliente();

		return cliente;
	}
}

Un hombre sabio dijo una vez: Siempre que puedas trabajar con una interfaz hazlo, evita usar implementaciones concretas.

Ahora ya no estamos usando implementaciones concretas, no estamos acoplando el código. Simplemente decimos que necesitamos una implementación de IMiRepositorio y otra de IMiServicio. Tenemos que pasar esas implementaciones en el constructor de la clase, así podemos pasar nuestras propias implementaciones a la hora de hacer unit test. De esta sencilla manera hemos solucionado todos los problemas que he expuesto antes.

Ahora bien… ¿No sigue siendo un problema tener que ir pasando esas implementaciones a cada clase que lo necesite y a mano? No. Existen una multitud de librerías que hacen el trabajo sucio por nosotros. Éstas librerías tienen unos componentes que se llaman Contenedores que son los encargados de suplir todas estas implementaciones a quien las necesite de forma automágica.

Bueno, en los próximos artículos veremos ejemplos reales de Dependency Injection usando WPF y ASP.NET MVC 3.

• Dependency Injection: ¿Por qué?
• Dependency Injection: MVVM Light + WPF + Unity
• Dependency Injection: ASP.NET MVC 3 con Ninject

Nos vemos en el primer artículo.

¿Os acordás del tuto de Entity Framework Code-First?

Seguro que sí. Pero ahora vamos a dar el segundo paso en este tema.

Abrimos nuestra aplicación (Si no la tenéis, podéis descargarlar de aquí). Vale, nuestra misión es poder desplegar la aplicación en un entorno web el cual no tiene ni Entity Framework ni SQL Server Compact Edition 4, así que vamos a tener que colocar todos los .DLL necesarios para que funcione.

¿Fácil verdad? (No realmente, me costó más de 5 horas lograr la combinación perfecta ).

Vamos allá. Necesitamos:

• Entity Framework
• SQL Server CE 4
• Librería de SQL Server CE 4 para Entity Framework
• Ficheros .DLL nativos de SQL Server CE 4

Empezamos con NuGet (esto es obligatorio, nos simplifica todo el trabajo), vamos a su consola de gestión de paquetes y hacemos un:

install-package EFCodeFirst.SqlServerCompact

͉sto nos instalará las 3 primeras cosas de la lista. Además nos añadirá una regla al Web.config:

  <system.data>
    <DbProviderFactories>
      <remove invariant="System.Data.SqlServerCe.4.0" />
      <add name="Microsoft SQL Server Compact Data Provider 4.0" invariant="System.Data.SqlServerCe.4.0" description=".NET Framework Data Provider for Microsoft SQL Server Compact" type="System.Data.SqlServerCe.SqlCeProviderFactory, System.Data.SqlServerCe, Version=4.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91" />
    </DbProviderFactories>
  </system.data>

Quizá sea esto lo más importante de todo, pues esto es lo que le indica al servidor que framework de datos estamos usando, sin esto nos dará un hermoso error diciendo que no encuentra dicho framework.

Vale, ya podemos hacer el despliegue.

¿Desplegado? Guay. Si nos fijamos, en el directorio /bin de nuestra aplicación tendremos 4 .DLLs (entre otros)

• EntityFramework.dll
• System.Data.SqlServerCe.dll
• System.Data.SqlServerCe.Entity.dll
• WebActivator.dll (necesario para el anterior)

Ya tenemos los .DLL’s ‘managed’, ahora necesitamos los nativos. ¿Dónde están? Vamos al directorio packages de nuestra aplicación, aquí encontramos un directorio por cada librería que hemos descargado con NuGet. Nos vamos al de Sql Server CE y dentro de NativeBinaries copiamos ambos directorios (x86 y amd64) al directorio /bin de nuestra aplicación.

Nada más, con esto ya tenemos funcionando nuestra aplicación usando Entity Framework y Sql Server CE 4.

Para muestra un botón.

Hasta otra!