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 )

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!

Hoy vamos a hablar de una de las formas que tenemos para crear una base de datos para nuestro proyecto. Concretamente de Entity Framework Code-First.

Antes de hablar de EF Code-First vamos a recordar brevemente cual es la manera común de crear una base de datos usando Entity Framework:

Si queríamos hacer uso de bases de datos en nuestra aplicación, lo más común era crear una base de datos (Usando Sql Server normal, express o compact edition), crear sus tablas y añadir algúna que otra fila para probar nuestra base de datos.

Una vez teníamos nuestra base de datos lista, creabamos un ASP.NET Entity Data Model que haría de intemerdiario entre nuestra aplicación y la base de datos. Dicho .edmx (Entity Data Model) GENERABA clases por cada tabla de nuestra base de datos.

Por ejemplo, si teníamos una clase Persona y una clase Trabajo, el Entity Data Model generaría una clase llamada Personas y otra llamada Trabajos que serían como ya he dicho, la representación de las tablas de la base de datos en clases C#.

La idea es buena, muy buena. El problema es que las clases que se generan, pueden contener mucha redundancia y por normal general no son nada limpias (Luego veremos un ejemplo).

Entonces… ¿Hay alguna otra manera? Por supuesto. Aquí es donde entra:

Entity Framework Code-First

Como su nombre indica (El código primero), nos incita a escribir primero las clases que representan las tablas y luego crear dichas tablas.

En otras palabras, crearemos una clase por cada tabla de la base de datos, y luego generaremos dichas tablas automáticamente (sin redundancias ni nada).

Para este ejemplo vamos a usar ASP.NET MVC 3 y Sql Server Compact Edition 4. En caso de que no lo tengás instalado, podéis usarlo en cualquier otro tipo de aplicación, WPF, ASP.NET 4… La idea y el conocimiento adquirido vale para cualquier otro tipo de proyecto.

Aún así, recomiendo usar SQLServerCE 4 a todos aquellos que necesiten bases de datos pequeñitas y embebidas y así no tirar de mastodontes como Sql Server.

NOTA: Necesitas del Service Pack 1 de VS2010 instalado para poder hacer uso de SQLServerCE 4 (A dia de hoy es beta, pero perfectamente usable)

Pensando que tenéis instalado Asp.NET MVC 3, SQl Server CE 4 (tanto toolkit como el runtime) y VS2010 SP1 Beta pues vamos allá:

Iniciamos un nuevo proyecto ASP.NET MVC 3, lo llamaremos: TutorialEFCodeFirst. Le decimos que queremos una aplicación de internet para no tener que marearnos con cosas irrelevantes para este artículo.

Una vez tengamos nuestro proyecto creado, necesitamos añadir Entity Framework a nuestro proyecto, para ello lo mejor sería usar NuGet para facilitarnos la vida.

Abrimos la consola de NuGet yendo al menú View->Other Windows->Package Manager Console. Una vez en la consola simplemente tenemos que teclear:

Install-package EFCodeFirst

Con esto ya tendremos la librería cargada en nuestro proyecto.

Ahora vamos con la base de datos… ¿Qué vamos a representar? Qué tal si seguimos con el ejemplo anterior de personas y trabajos? Pues vamos a ello:

Click derecho en Models, añadir nueva clase, la cual llamaremos Persona:

public class Persona
{
	public int ID { get; set; }
	public int TrabajoID { get; set; }
	public string Nombre { get; set; }
	public int Edad { get; set; }

	public virtual Trabajo Trabajo { get; set; }
}

Añadiremos también una clase llamada Trabajo:

public class Trabajo
{
	public int ID { get; set; }
	public string Nombre { get; set; }
	public string Descripcion { get; set; }

	public virtual ICollection<Persona> Personas { get; set; }
}

Como véis, no dejan de ser clases normales. No tienen nada fuera de lo común y no heredan de ningún tipo de clase o interfaz. Lo interesante es:

La relación entre la clase Trabajo y Persona es 1:N. Eso quiere decir que un trabajo puede hacerlo varias personas y una persona tiene un trabajo. La teoría de base de datos nos dice que en estos casos, la clave de la tabla que tiene el 1 se propaga a la clase N. En este caso, en la clase/tabla Persona tendremos una referencia al ID de Trabajo.

A parte de esto, cada clase ha de tener digamos un “enlace” con cada clase que se relaciona. En este caso:

Persona se relaciona con Trabajo y como Persona solo se relaciona con una instancia de Trabajo pues guardamos una simple instancia.
En el otro caso, como Trabajo se relaciona con muchas Personas pues guardará una colección de estas.
Vale, ya tenemos las clases que serán las tablas de la base de datos, pero todavía necesitamos la última pieza que hará que todo esto funcione.

Si habéis generado las clases a partir de la base de datos como comenté al principio del artículo, veréis que además de las clases, genera una clase llamada Contexto la cual nos hace de intermediario entre la base de datos y nuestro código.

En nuestro caso, necesitamos escribir esa clase manualmente, pero claro, queda mucho más simple que su homóloga. Por simplicidad, crearemos este contexto en la carpeta Models:

public class TutorialContext : DbContext
{
	public DbSet<Persona> Personas { get; set; }
	public DbSet<Trabajo> Trabajos { get; set; }
}

Como véis, es una clase bastante sencillita, simplemente creamos una propiedad del tipo DbSet por cada clase que pasará a ser una tabla.

Ahora necesitamos especificar la cadena de conexión a la base de datos que se va a generar. Para el caso de SQL Server CE 4 sería así (tenemos que escribirla en el Web.config):

<connectionStrings>
	<add name="ApplicationServices"
		 connectionString="data source=.SQLEXPRESS;Integrated Security=SSPI;AttachDBFilename=|DataDirectory|aspnetdb.mdf;User Instance=true"
		 providerName="System.Data.SqlClient" />
	<add name="TutorialContext" connectionString="Data Source=|DataDirectory|tutorial.sdf" providerName="System.Data.SqlServerCE.4.0"/>
</connectionStrings>

La cadena de conexión consta de 3 partes.

En name pondremos el nombre de la clase que hace de Contexto, en nuestro caso es TutorialContext.
En connectionString colocamos la ruta donde irá nuestra base de datos, en nuestro caso irá a la carpeta App_Data(DataDirectory).
en providerName colocamos la librería que usaremos para esto, en este caso es la libreria de SQL Server CE 4.

Ya está, no hay más. Nuestra base de datos ya está lista. Hemos creados las clases, hemos creado el contexto y finalmente hemos puesto la cadena de conexión. Nuestra base de datos se generará cuando se haga uso de ella por primera vez.

Vamos a probarla.

Por simplicidad abrimos el HomeController y ahí probaremos nuestra base de datos.

Cambiaremos el método Index por el nuestro propio:

public ActionResult Index()
{
	var db = new TutorialContext();

	var personas = from p in db.Personas
				   select p;

	return View(personas.ToList());
}

Nada fuera de lo común. El uso de nuestra base de datos es exactamente el mismo que si hubiesemos usado el otro método. Simplemente instanciamos el contexto, y como ejemplo creamos una lista de personas y la enviamos a la vista.

NOTA: Es recomendable crear un repositorio que haga de intermediario entre nuestra aplicación y la base de datos, pero para simplificar el artículo vamos a usar el contexto directamente.

Abrimos Index.cshtml y modificamos la vista acorde a nuestra aplicación:

@model IEnumerable<TutorialEFCodeFirst.Models.Persona>

@{
    ViewBag.Title = "Lista de personas";
}

<h2>Lista de personas</h2>

@foreach (var per in Model)
{
    <div>
        <h2>@per.Nombre - @per.Edad</h2>
        @if (per.Trabajo != null)
        {
            <h3>@per.Trabajo.Nombre</h3>
        }
    </div>
}

Si ejecutamos nuestra aplicación veremos que no sale ninguna persona:

Normal, no hemos añadido ninguna persona.

Ahora bien, si en el Visual Studio hacemos click en el botón para ver todos los archivos del proyecto, podemos ver que dentro de App_Data aparece nuestra base de datos.

Hacemos click derecho en la base de datos y le damos a incluir en el proyecto.

Si ahora hacemos doble click en la base de datos, podremos ver la información de esta. Podremos ver sus tablas, etc.

¿Trabajoes? A mi me ha creado la tabla con ese nombre… No pasa nada, podemos decirle al contexto qué nombre usar a la hora de crear la tabla, es tan fácil como sobreescribir un método:

protected override void OnModelCreating(ModelBuilder modelBuilder)
{
	modelBuilder.Entity<Persona>()
		.ToTable("Personas");
	modelBuilder.Entity<Trabajo>()
		.ToTable("Trabajos");
}

Simplemente a la hora de mapear las clases a tablas, elegimos el nombre.

Ahora sí:

Ya que estamos vamos a añadir algunos datos, ¿No?

Hacemos click derecho en la tabla Trabajos y le damos a que nos muestre los datos de las personas. Lo dejaremos así:

Ahora hacemos lo mismo con la tabla Personas pero usando estos datos:

Ahora que tenemos datos, simplemente tenemos que ejecutar otra vez nuestra aplicación:

Ahí están nuestros datos!!

¿Fácil verdad? Solo hemos tenido que crear las clases que serán tablas, el contexto, la cadena de conexión y finalmente introducir algunos datos de prueba.

Bueno, hasta aquí la introducción a EF Code First. Espero vuestros comentarios.

Por fin soy usuario de Windows Phone 7. Llevaba un tiempo detrás de el para poder desarrollar para el.

En este caso ha sido un HTC 7 Trophy de Vodafone.

Me gustaría centrarme un poco más en el teléfono que en SO en sí, puesto que todos sabemos qué tan bueno es

El telefono en si tiene un buen acabado y un buen tacto.

Tiene 4 botones. Los dos de volumen, el power y el de la cámara (lo cual es un bueeeen extra).

Ya hablando de cámara, no deja de ser una cámara normal de 5mp con una calidad puerca, las cosas como son, de nada valen los megapíxeles si el objetivo es mas pequeño que una uña del dedo chico… Eso sí, tiene un flash bastante hermoso.

Es capaz de grabar videos a 720p, pero seguimos en las mismas, con ese objetivo no se consigue nada en condiciones.

Aparte de los botones físicos, tiene los 3 típicos botones de todo teléfono WP7, el de ir atrás, el de windows (boton inicio) y el de buscar. Estos 3 botones son táctiles (vamos, forman parte de la pantalla). La verdad es que el tacto es muy bueno y reaccionan perfectamente los botones.

Es un teléfono con una pantalla de 3,8″ y la verdad, es gigante y la calidad de imagen la veo bastante bien, la reacción al tacto, a los movimientos… Todo está bien bien.

Eso si, tiene una pega, al parecer están veniendo mal muchos de estos terminales. Es como si el protector de la pantalla estuviese mal pegado y le empiezan a salir burbujas debajo de este. Nada grave, pero es una molestia tener que estar detrás de htc para que te lo cambien y tal.

Por otro lado, WP7 está bien, solo que todavía han de ir puliendo algún que otro fallo y pequeñas cosas más.

Yo recomiendo este teléfono sin duda, es una joya, aunque eso si, esperaría un poco a ver si sacan una remesa que no tenga el problema cosmético que tiene este.