ASP.NET MVC, Controles Chart y Ajax…

Supongo que la gran mayoría de vosotros, conoceréis los controles de gráficos de ASP.NET. José M. Aguilar hizo un excelente post sobre ellos aquí (http://geeks.ms/blogs/jmaguilar/archive/2008/12/14/microsoft-chart-control-para-asp-net-3-5-sp1.aspx).

Utilizarlos es realmente simple… basta con que os los descargueis de la web de Microsoft y después de instalarlos agregueis las siguiente líneas en el web.config:

<add path="ChartImg.axd" verb="GET,HEAD" 
type="System.Web.UI.DataVisualization.Charting.ChartHttpHandler,
System.Web.DataVisualization, Version=3.5.0.0, Culture=neutral,
PublicKeyToken=31bf3856ad364e35
" validate="false"/>

En la sección <httpHandlers> y la siguiente:

<add tagPrefix="asp" 
namespace="System.Web.UI.DataVisualization.Charting"
assembly="System.Web.DataVisualization, Version=3.5.0.0,
Culture=neutral, PublicKeyToken=31bf3856ad364e35
"/>

En la sección <controls>.

Despues ya podeis arrastrar un Chart control desde la toolbox a vuestra página ASP.NET y empezar a trabajar con él.

Si, como yo, os encanta ASP.NET MVC sabed que podeis usar este control sin ningún problema (http://code-inside.de/blog-in/2008/11/27/howto-use-the-new-aspnet-chart-controls-with-aspnet-mvc/).

El único temilla a tener en cuenta es si se quiere actualizar sólo el gráfico mediante Ajax (usando ASP.NET MVC).

Suponed una vista parcial (Chart.ascx) con el siguiente código que muestra un gráfico con contenido random:

<%@ Control Language="C#" Inherits="System.Web.Mvc.ViewUserControl" %>
<asp:Chart ID="chart" runat="server" Palette="Fire" >
    <Series>
        <asp:Series Name="D1" ChartType="StackedColumn" />
        <asp:Series Name="D2" ChartType="StackedColumn" />
    </Series>
    <ChartAreas>
        <asp:ChartArea Name="ChartArea1">
        </asp:ChartArea>
    </ChartAreas>
</asp:Chart>
<script runat="server">
    protected void Page_Load(object sender, EventArgs e)
    {
        Random r = new Random();
        this.chart.Series["D1"].Points.Add(r.Next(100));
        this.chart.Series["D2"].Points.Add(r.Next(100));        
    }
</script>

Y otra vista (Victories.aspx) que contiene el siguiente código (entre otro):

    <%=Ajax.ActionLink("Actualizar", "Victories", 
new RouteValueDictionary(new { Days = 7, Interval = 1 }),
new AjaxOptions() { UpdateTargetId = "chart" }) %> <div id="chart" />

El enlace “Actualizar” envia una petición Ajax al controlador actual para que invoque la acción “Victories” y con el resultado actualice el div “chart”.

La acción “Victories” está implementada en el controlador tal como sigue:

public ActionResult Victories(int? days, int? interval)
{
    return PartialView("Chart");
}

De este modo a cada click del enlace se genera un nuevo gráfico aleatorio y se actualiza via Ajax la página…

… en teoria, porque en la práctica no se ve nada. Analizando con firebug lo que ha sucedido se puede observar que se lanza una excepción:

[HttpException (0x80004005): Error executing child request for ChartImg.axd.]

La solución? Caer en la cuenta de que las peticiones Ajax usan POST por defecto, así que o bien cambiamos la línea que añadimos en el web.config para que soporte POST:

<add path="ChartImg.axd" verb="GET,HEAD, POST" 
type="System.Web.UI.DataVisualization.Charting.ChartHttpHandler,
System.Web.DataVisualization, Version=3.5.0.0, Culture=neutral,
PublicKeyToken=31bf3856ad364e35
" validate="false"/>

o bien le indicamos  a la petición Ajax que sea usando “GET”:

<%=Ajax.ActionLink("Last Week", "Victories", 
new RouteValueDictionary(new { Days = 7, Interval = 1 }),
new AjaxOptions() { HttpMethod="GET", UpdateTargetId = "chart" }) %>

Saludos!

Interfaces “Dockables” con AvalonDock

Hace algún tiempo escribí como integrar AvalonDock con PRISM. En el post daba por asumidos algunos conceptos de AvalonDock, pero algunos comentarios recibidos me han pedido si puedo profundizar un poco, así que voy a ello. Vamos a ver como crear paso a paso una aplicación AvalonDock y luego, en otro post ya veremos como podemos PRISMearla… 🙂

AvalonDock es una librería para la creación de interfaces con ventanas flotantes (al estilo del propio Visual Studio). Según su creador soporta también winforms, aunque yo siempre la he usado con WPF, así que nada puedo deciros de su integración con winforms.

Hay un tutorial de AvalonDock en el blog de su creador (http://www.youdev.net/post/2008/09/25/AvalonDock-Tutorial.aspx) que aunque muy básico explica los conceptos clave… echadle una ojeada si os apetece 🙂

Supongo que teneis instalada AvalonDock… si usais el instalador, os creará una toolbar en Visual Studio con los controles de AvalonDock, no és imprescindible pero ayuda 🙂

El primer paso es crear una aplicación WPF, añadir una referencia a AvalonDock.dll y en la ventana principal, debemos añadir el componente padre de AvalonDock, el DockingManager:

<Window x:Class=”DockReader.Window1″ xmlns=”http://schemas.microsoft.com/winfx/2006/xaml/presentation” xmlns:x=”http://schemas.microsoft.com/winfx/2006/xaml” Title=”Window1″ Height=”300″ Width=”300″ xmlns:ad=”clr-namespace:AvalonDock;assembly=AvalonDock”> <Grid> <ad:DockingManager Name=”dockManager”/> </Grid> </Window>


En este caso DockManager ocupa todo el espacio disponible en la Grid del control. Si nos interesa tener algún control en la ventana principal que no participe del sistema de ventanas flotantes (p.ej. una statusbar o una ribbon siempre visibles y fijas), podemos colocarla en alguna otra fila de la grid:

<Window x:Class=”DockReader.Window1″ xmlns=”http://schemas.microsoft.com/winfx/2006/xaml/presentation” xmlns:x=”http://schemas.microsoft.com/winfx/2006/xaml” Title=”Window1″ Height=”300″ Width=”300″ xmlns:ad=”clr-namespace:AvalonDock;assembly=AvalonDock”> <Grid> <Grid.RowDefinitions> <RowDefinition Height=”50″/> <RowDefinition/> </Grid.RowDefinitions> <!– ToolBar fija –> <ToolBar Grid.Row=”0″> <Button> <Image Source=”/DockReader;component/open.png” Height=”32″ Width=”32″></Image> </Button> </ToolBar> <!– Docking Manager –> <ad:DockingManager Grid.Row=”1″ Name=”dockManager”/> </Grid> </Window>


El DockingManager por sí solo no hace nada… tenemos que rellenarlo y para ello podemos usar los dos contenidos que tiene AvalonDock:

  • DockableContent: Un DockableContent se puede “dockar” en cualquier parte del DockingManager y también puede aparecer en forma de ventana flotante.
  • DocumentContent: Los DocumentContent aparecen “fijos” en una zona, y pueden “dockarse” en cualquier parte de esta zona (y generalmente no aparecen en forma de ventanas flotantes).

P.ej. en Visual Studio las distintas ventanas con documentos serian DocumentContents, y el restro de ventanas flotantes (p.ej. la toolbox) serian DockableContents.

Para que AvalonDock funcione correctamente debemos incrustar los DockableContent y los DocumentContent en sus propios paneles que son DocumentPane (para contener DocumentContents) y DockablePane para contener DockableContents.

P.ej. si colocamos un DocumentPane con dos DocumentContent dentro del DockingManager, obtenemos la siguiente interfaz:

image image

Como podeis observar sólo con un DocumentPane ya tenemos una interfaz totalmente dockable.

Si queremos combinar varios DocumentPane (cada uno con sus ContentPane) y/o varios DockablePane (cada uno con sus DockableContents) debemos usar un panel dentro del DockingManager. P.ej, la siguiente interfaz és el mismo ContentPane de antes y un DockableContent, todo ello dentro de un StackPanel:

image

El código XAML sería tal y como sigue:

<!– Docking Manager –> <ad:DockingManager Grid.Row=”1″ Name=”dockManager”> <StackPanel Orientation=”Horizontal”> <ad:DocumentPane Width=”200″> <ad:DocumentContent> <Label>Documento 1</Label> </ad:DocumentContent> <ad:DockableContent> <Label>Documento 2</Label> </ad:DockableContent> </ad:DocumentPane> <ad:DockablePane Width=”80″> <ad:DockableContent> <Button>Botón Dockable</Button> </ad:DockableContent> </ad:DockablePane> </StackPanel> </ad:DockingManager>


 

 

Esta ventana tiene el problema de que el tamaño del DocumentPane y del DockablePane está fijo… AvalonDock nos ofrece un panel (ResizingPanel) que integra un splitter… simplemente cambiando el StackPanel por un ResizingPanel nuestra interfaz ya es totalmente funcional!

Vamos a hacer una aplicación completa: un lector de ficheros XPS. En la parte izquierda tendremos un DocumentPane con los distintos ficheros abiertos, y en la parte derecha una lista con los nombres de los ficheros abiertos.

El XAML de la ventana principal quedaria:

<Window x:Class=”DockReader.Window1″ xmlns=”http://schemas.microsoft.com/winfx/2006/xaml/presentation” xmlns:x=”http://schemas.microsoft.com/winfx/2006/xaml” Title=”Window1″ Height=”300″ Width=”300″ xmlns:ad=”clr-namespace:AvalonDock;assembly=AvalonDock”> <Grid> <Grid.RowDefinitions> <RowDefinition Height=”50″/> <RowDefinition/> </Grid.RowDefinitions> <!– ToolBar fija –> <ToolBar Grid.Row=”0″> <Button x:Name=”cmdAbrir” Click=”cmdAbrir_Click”> <Image Source=”/DockReader;component/open.png” Height=”32″ Width=”32″></Image> </Button> </ToolBar> <!– Docking Manager –> <ad:DockingManager Grid.Row=”1″ Name=”dockManager”> <ad:ResizingPanel Orientation=”Horizontal”> <ad:DocumentPane x:Name=”docsPane”> </ad:DocumentPane> <ad:DockablePane> <ad:DockableContent> <DockPanel> <Label DockPanel.Dock=”Top”>
Ficheros Abiertos:</Label> <ListBox x:Name=”openFiles”/> </DockPanel> </ad:DockableContent> </ad:DockablePane> </ad:ResizingPanel> </ad:DockingManager> </Grid> </Window>


Vemos la toolbar fija (fuera del DockingManager). Luego tenemos un DocumentPane vacío (inicialmente no tenemos cargado ningún documento) y también vemos un DockablePane que tiene un DockableContent con una label y la listbox…

En la función gestora del evento Click del botón “cmdAbrir”, mostramos un OpenFileDialog para seleccionar un fichero xps:

private void cmdAbrir_Click(object sender, RoutedEventArgs e) { OpenFileDialog ofd = new OpenFileDialog(); ofd.AddExtension = true; ofd.DefaultExt = “.xps”; ofd.Multiselect = false; ofd.CheckFileExists = true; ofd.Filter = “Documentos XPS | *.xps”; if (ofd.ShowDialog() == true) { string s = ofd.FileName; CrearNuevoVisor(s); } }


Finalmente la función CrearNuevoVisor es la que creará un DocumentContent con el contenido del fichero XPS:

private void CrearNuevoVisor(string fname) { // Creamos el DocumentContent DocumentContent dc = new DocumentContent(); dc.Closed += new EventHandler(Document_Closed); dc.Title = System.IO.Path.GetFileNameWithoutExtension(fname); this.files.Add(dc.Title); // Carga el XPS y crea un DocumentViewer XpsDocument doc = new XpsDocument(fname, FileAccess.Read, CompressionOption.NotCompressed); DocumentViewer dv = new DocumentViewer(); // Muestra el XPS en el DocumentViewer dv.Document = doc.GetFixedDocumentSequence(); // Incrusta el DocumentViewer en el DocumentContent dc.Content = dv; // Incrusta el DocumentContent en el ContentPane this.docsPane.Items.Add(dc); }


El código es realmente simple, no? Si os preguntais que es this.files, os diré que es una ObservableCollection<string> que está enlazada a la listbox:

private ObservableCollection<string> files; public Window1() { InitializeComponent(); this.files = new ObservableCollection<string>(); this.openFiles.ItemsSource = this.files; }


Finalmente, en el método Document_Closed lo único que hacemos es eliminar de this.files la cadena que hemos añadido antes (no pongo el código, ya que es trivial).

Con esto ya tenemos un lector de XPS completamente funcional y con una interfaz totalmente “dockable”…

image image

En un próximo post veremos como convertir este DockReader en una aplicación compuesta usando PRISM!

Saludos!

La sencillez de una interfaz compleja

Hace algún tiempecillo escribí un artículo para el e-zine de raona, que enviamos a distintos clientes. En el artículo esbozaba los patrones básicos para diseñar interfaces de usuario compuestas. Posteriormente me surgió la idea de que una ampliación de dicho artículo, donde se mostrasen ejemplos en PRISM y WPF de estos conceptos podría ser interesante. Afortunadamente en DotNetMania pensaron lo mismo y es por ello que en la revista de este marzo hay un artículo con este mismo título.

Lo que ahora sigue és el artículo original, el que escribí para el e-zine. Aunque el de DotNetMania describe las mismas ideas, ambos artículos tienen poco a ver (tanto en contenido, como en enfoque como en extensión). Como creo que el artículo del e-zine tambiém tiene su interés, me he tomado la libertad de postearlo aquí 🙂

PD: Por si os interesa, los distintos e-zines que vamos sacando en raona, los podeis consultar en la sección de ezines de raona.

La sencillez de una interfaz compleja (versión e-zine).

Cada vez las aplicaciones son más y más complejas, y los usuarios son más y más exigentes. Los desarrolladores debemos afrontar este doble reto siendo capaces de proporcionar mejores y más complejas aplicaciones, en cada vez menos tiempo. Evidentemente este es un proceso global, que afecta a todo el desarrollo de una solución de software, pero me gustaría centrarme en los retos concretos que esto implica cuando hablamos de interfaces de usuario. No en vano, la interfaz de usuario es el punto de conexión entre el usuario y la aplicación. Es un elemento crítico y de su implementación depende en buena medida el éxito final de toda la aplicación.

Interfaces complejas

Las aplicaciones actuales demandan interfaces de usuario complejas a nivel técnico pero que a la vez sean sencillas de utilizar y de mantener. Que se adapten a cualquier tipo de usuario, que tanto usuarios expertos como inexpertos se sientan a gusto utilizándola. En resumen que la experiencia del usuario al utilizar la interfaz sea plena y que nuestra aplicación sea usable por cualquier usuario.

El término interfaz compleja, no quiere referirse al aspecto visual o usable si no al hecho de que cada vez es más complejo y difícil realizar interfaces que permitan conjugar las crecientes posibilidades de la aplicación con la sencillez de uso y la usabilidad. Este es el reto que debemos solucionar.

Nuevas tecnologías, nuevas posibilidades

Con la aparición de WPF, Microsoft ha dotado a los desarrolladores de un montón de nuevas posibilidades para la construcción de interfaces. El hecho de disponer de un lenguaje declarativo (XAML) para definir las interfaces permite la separación entre dos roles básicos hoy en día: los diseñadores y los desarrolladores. Pero separar desarrolladores y diseñadores es sólo un primer paso (un primer gran paso) pero no soluciona la problemática de fondo: el modo en cómo están diseñadas y desarrolladas las interfaces de usuario.

El mecanismo habitual de desarrollar interfaces de usuario en .NET, viene influenciado de los tiempos de Visual Basic. Es un patrón que consiste en una clase contenedora (llamada comúnmente formulario) que contiene a los controles y toda la lógica asociada a dichos controles. Por norma general el formulario se suscribe a los eventos de los controles a los que contiene y realiza la lógica apropiada en las funciones gestoras de dichos eventos. La ventaja de este modelo de programación es que es sencillo, intuitivo y fácil de aprender. Las desventajas son que al tener unidas la lógica con la presentación se vuelve más complejo el mantenimiento tendiendo a colapsar en grandes proyectos y se dificulta la separación del desarrollo entre varios equipos.

Una de las claves para desarrollar interfaces de usuario complejas y que resulten mantenibles es desacoplar la presentación de la lógica de dicha presentación. WPF presenta algunas novedades que ayudan a conseguir dicho desacople:

  1. Commands: Permite desacoplar los eventos de los controles de la gestión de dichos eventos y unificar en un mismo punto la gestión de distintos eventos de distintos controles pero que realizan la misma acción (p.ej. un botón de una toolbar y una entrada de menú).
  2. Routed Events: Permiten tratar en un solo contenedor cualquier evento generado por cualquier de los controles “hijos” (estén en el nivel de profundidad que estén).

Estas novedades aunque interesantes, por si solas no son suficientes para desacoplar totalmente la presentación y su lógica. Para ello hace falta un cambio de paradigma, un nuevo modelo.

Composite Application Library

Composite Application Library (CAL) también conocida por su nombre en código PRISM, es un framework lanzado por la gente de “Patterns & Practices” para ayudar en la construcción de aplicaciones complejas utilizando WPF.

CAL se basa en varios patrones para ayudar a conseguir un desacople total entre la presentación y la lógica de presentación. A continuación comentaremos tres de los patrones más relevantes de CAL.

Inversion of Control (IoC)

Este patron desacopla una clase en concreto de otra clase de las clases que utiliza, es decir de sus referencias:

Dependencias entre clsases

La clase ClassA utiliza dos servicios (ServiceA y ServiceB) y por lo tanto tiene referencias directas a ellos. Esto implica, entre otras cosas, que si queremos modificar las referencias debemos modificar el código fuente de ClassA. Para desacoplar la clase de sus referencias la solución es añadir un componente externo que se encargue de encontrar y gestionar las referencias de la clase ClassA. En función de cómo diseñemos este elemento externo hablaremos de un patrón ServiceLocator o de Dependency Injection.

Service locator &  Dependency Injection

Con ServiceLocator la clase ClassA sólo contiene una referencia al Locator siendo esta clase la que obtiene y devuelve la referencia adecuada a la clase. El Locator NO instancia los servicios, simplemente los localiza (los servicios han estado instanciados previamente por alguien): mientras un servicio esté registrado, el Locator lo encontrará. CAL utiliza Unity para ofrecer un Service Locator, lo que nos permite instanciar y registrar servicios que luego serán utilizados en cualquier parte de la aplicación.

Con Dependency Injection, existe un Builder que crea el objeto del servicio y lo “incrusta” en alguna propiedad específica de la clase ClassA (o bien en algún parámetro del constructor). CAL utiliza Unity para proporcionar Dependency Injection.

Separated Presentation

Si IoC nos permite desacoplar nuestras clases de las referencias que necesitan, el conjunto de patrones conocidos como “separated presentation”, nos permiten separar la presentación de la parte de la lógica que gestiona la presentación.

Existen varios patrones que implementan “separated presentation” siendo los más concidos MVP (Model – View – Presenter) o MVVM (Model – View- ViewModel). Debido a las capacidades de WPF se tiende a utilizar más MVVM (mientras que MVP es más frecuente en aplicaciones Windows forms p.ej), debido a que MVVM se basa en uno de los aspectos más potentes de WPF: su data binding.

El patrón MVVM se basa en tres elementos:

  • Vista (View): Contiene los elementos visuales (controles). En el caso de WPF suele estar creada por un diseñador e implementada vía XAML
  • Modelo (Model): Contiene los datos que muestra la vista. En este punto es cuando se utiliza básicamente el data binding, para enlazar los valores de los controles de la vista a valores de distintos elementos del modelo.
  • Modelo de Vista (ViewModel): En interfaces sencillas, la vista se puede enlazar directamente con el modelo, pero en interfaces complejas no suele ser posible. En muchos casos el Modelo puede tener multitud de información que no se puede mapear a valores de los controles o bien nuestra vista debe realizar y mantener valores “temporales” que no forman parte estricta del modelo. Es en estos casos donde entra en escena el “ViewModel”, actuando de puente proporcionando transformadores para poder enlazar los controles de la vista y commands para que la vista pueda interactuar con el modelo.

De esta manera no existe más una clase “formulario” que contiene los controles y toda la lógica asociada a ellos.

Event Aggregator

Un Event Aggregator es la implementación de un modelo de eventos publish and subscribe, donde cuando alquien quiere recibir un evento se suscribe a este tipo de evento en particular. Cuando alguien quiere enviar un evento lo publica y el event aggregator se ocupa de que todos los que se hayan suscrito a este tipo de evento lo reciban. De esta manera se desacoplan totalmente los publicadores de eventos de sus suscriptores.

Conclusiones

Para desarrollar interfaces complejas que a la vez sean amigables para el usuario y mantenibles para el desarrollador es necesario involucrar a los diseñadores por un lado y desacoplar la presentación de la lógica que la gestiona por otro. Gracias a XAML, WPF permite que los diseñadores se integren totalmente en el ciclo de desarrollo, y el uso de determinados patrones permite desacoplar los distintos elementos que conforman la inferfaz de usuario. CAL es un framework y una guía de estilo que basándose en dichos patrones y en las funcionalidades inherentes a WPF nos permite desarrollar aplicaciones complejas que sean mantenibles y amigables a la vez.

Referencias

PRISM y Winforms: Mostrar vistas en nuevos formularios

En un post anterior (PRISM y Winforms), comentaba como usar PRISM para realizar aplicaciones Winforms.

Un comentario de Jose en esta entrada, me ha motivado a escribir el siguiente post, para mostrar como podríamos mostrar vistas en regiones que estén incrustadas no en un UserControl (típicamente un Panel) de la ventana principal, sino incrustadas en un nuevo formulario.

Para poder usar regiones en Winforms era necesario definirnos un RegionAdapter para la clase “Control” que era básicamente el objetivo del post anterior. En el método Adapt() teníamos el código que “incrustaba” la vista dentro del control. Dicho método recibía (de PRISM) la región y el target, o control donde colocar dicha región.

Antes que nada recordad tres conceptos que a veces se confunden:

  1. Region: En PRISM una región es un conjunto de vistas (algunas activas, otras no activas) que se muestran en algún sitio determinado.
  2. Target: El target de una región es el lugar donde se muestran. P.ej. un TableLayout podría ser el target de una región y cada vista de la región podría mostrarse en distintas celdas.
  3. Vista: Una vista muestra una determinada información. P.ej. si tenemos una aplicación que nos muestra la cotización de varias acciones, podríamos tener varias instancias de una vista, donde cada instancia nos mostraría la cotización de una acción. En winforms generalmente es un UserControl.

En PRISM las vistas se colocan en regiones y las regiones se incrustan en los targets… recordad que una región puede tener varias vistas.

En el RegionAdapter que vimos en el post anterior, siempre recibíamos la región y el target. El target ya estaba creado porque era un control ya existente en la ventana principal.

Esto no nos sirve si queremos mostrar una vista en un formulario nuevo ya que ahora debemos crear el formulario cada vez que queramos mostrar la región… ¿como podemos hacerlo?

Además del método Adapt() que usamos en el post anterior, los RegionAdapter pueden redefinir otro método llamado AttachBehaviors. En este método podemos añadir la lógica que queramos para personalizar el comportamiento de la región… en este caso podremos aprovechar para crear el target.

Un vistazo al código…

El código que sigue a continuación es una adaptación de la clase WindowRegionAdapter de Composite WPF Contrib, que he adaptado para que funcione con Windows Forms.

El método AttachBehaviors lo redefinimos de la siguiente manera:

protected override void AttachBehaviors(IRegion region, 
    Form regionTarget)
{
    base.AttachBehaviors(region, regionTarget);
    FormRegionBehavior behavior = 
        new FormRegionBehavior
            (regionTarget, region, FormBorderStyle.FixedSingle);
    behavior.Attach();
}

Los parámetros que recibe son los mismos que Adapt: la región y el target (en este caso un Form) ya que derivamos de RegionAdapterBase<Form>. En este método creamos un objeto FormRegionBehavior que será el que tendrá todo el código para gestionar regiones que estén dentro de un formulario. En concreto dicha clase será la responsable de:

  1. Crear un formulario por cada nueva vista añadida a la región y incrustar dicha vista en el formulario
  2. Cerrar el formulario que contiene una vista si esta se elimina de la región.
  3. Eliminar una vista de la región si se cierra el formulario que la contiene.
  4. Activar o desactivar la vista cuando su formulario es activado o desactivado.

A continuación pongo el código más relevante de dicha clase. Al final del post adjunto una aplicación de demo.

1 y 2. Crear un formulario por cada nueva vista y eliminar el formulario de una vista eliminada

El método Attach() de la clase FormRegionBehavior de suscribe a los dos eventos CollectionChanged de las colecciones Views y ActiveViews de la región:

internal void Attach()
{
    IRegion region = _regionWeakReference.Target as IRegion;
    if (region != null)
    {
        region.Views.CollectionChanged +=
            new NotifyCollectionChangedEventHandler
                (Views_CollectionChanged);
        region.ActiveViews.CollectionChanged += 
            new NotifyCollectionChangedEventHandler
                (ActiveViews_CollectionChanged);
    }
}

En el método Views_CollectionChanged es donde sabemos si se ha añadido una vista a la región o se ha eliminado, y así podemos crear o destruir el formulario asociado:

private void Views_CollectionChanged(object sender,
NotifyCollectionChangedEventArgs e) { Form owner = _ownerWeakReference.Target as Form; if (owner == null) { Detach(); return; } if (e.Action == NotifyCollectionChangedAction.Add) { foreach (object view in e.NewItems) { // Creamos un formulario por cada vista y lo mostramos... } } else if (e.Action == NotifyCollectionChangedAction.Remove) { foreach (object view in e.OldItems) { // Buscamos el formulario que contiene cada vista // para cerrarlo y "disposarlo" 🙂 } } }

3. Eliminar la vista de la región si se cierra el formulario

Para ello, cuando creamos un formulario, nos suscribimos al evento Closed para poder eliminar la vista asociada a la región:

private void Form_Closed(object sender, EventArgs e)
{
    Form frm = sender as Form;
    IRegion region = _regionWeakReference.Target 
        as IRegion;
    if (frm != null && frm.Controls.Count > 0 
        && region != null)
        if (region.Views.Contains(frm.Controls[0]))
            region.Remove(frm.Controls[0]);
}

4. Activar o desactivar la vista cuando su formulario es activado o desactivado

Para ello, cuando creamos un formulario nos suscribimos a los eventos Activated y Deactivate, para desactivar o activar la vista correspondiente:

private void Form_Activated(object sender, EventArgs e)
{
    IRegion region = _regionWeakReference.Target 
        as IRegion;
    Form frm = sender as Form;
    if (frm != null && frm.Controls.Count > 0 &&
        !region.ActiveViews.Contains(frm.Controls[0]))
        region.Activate(frm.Controls[0]);
}

5. Algunas consideraciones finales

Para PRISM toda región tiene un solo contenedor (o target) que es aquel que se usa cuando se llama a AttachNewRegion. Aunque este RegionAdapter va creando distintos formularios, para PRISM la región debe estar vinculada a un único target… que debe existir cuando llamemos a  AttachNewRegion y cuyo tipo debe ser Form puesto que nuestro RegionAdapter trabaja con targets de tipo Form.

Esto nos deja en una situación curiosa, puesto que necesitamos tener un Form creado para poder crear la región. Aunque luego este formulario no contendrà ninguna de las vistas de la región. Consideraremos a este formulario el formulario padre, y cuando el formulario padre muera el RegionAdapter dejarà de tratar a la región (digamos que la región habrá muerto).

Otra cosa que también debemos solucionar es dado una vista, encontrar que formulario la contiene. El RegionAdapter no se guarda una lista de los formularios creados, en su lugar solo tiene una WeakReference al formulario padre (el usado para llamar a AttachNewRegion y que nunca contendrá vistas de esta región) y usa el formulario padre para encontrar a los formularios que contiene la vista. Esto es posible porque al crear un formulario que contiene una vista se indica que su padre es el formulario padre:

Form owner = _ownerWeakReference.Target as Form;
// Creamos un formulario por cada vista y lo mostramos...

frm.Owner = owner;

De este modo se puede usar la propiedad OwnedForms del formulario padre para iterar sobre todos los formularios creados y ver cual contiene la vista en cuestión.

Finalmente, el hecho de tener que pasar un formulario ya existente a AttachNewRegion, no es excesivamente problemático: lo más fácil es usar el formulario principal del programa!

Adjunto el programa de demostración. El RegionAdapter DialogRegionAdapter es el que muestra vistas en nuevos formularios, mientras que el RegionAdapter ControlRegionAdapter las muestra en paneles (de hecho en cualquier control).

Descargar el código de demostración.

Espero que os sea útil! 🙂

Evento ALM: Como Team System cambió mi (ciclo de) vida

Hola a todos!

Aprovecho la ocasión para comunicaros un evento que organizamos en raona, en colaboración con Microsoft, sobre ALM en general y Team System en particular.

Lo hemos llamado “Como Team System cambió mi (ciclo de) vida”. Durante unas 4 horas y pico, Magda, Enric y yo mismo (sí, nada es perfecto y yo voy a estar… pero no sufrais, ya dejaré hablar a los que saben :p) vamos a comentar distintos aspectos de Team System. Empezaremos con una introducción y luego iremos viendo aspectos concretos (personalización, distintos clientes de foundation server, team build,…).

El evento será en Madrid el 18 de marzo y en Barcelona al dia siguiente (o sea el 19).

Enlace de la página del evento en raona

Enlace del registro para Madrid

Enlace del registro para Barcelona

Esperamos veros por allí!!! 😉

Saludos!

[DllImport] y clases genéricas

Un post rápido para decir sólo dos cosas:

  • DllImport y clases genéricas no se llevan bien. Meter un DllImport en una clase genérica (o derivada de alguna genérica) lanza un TypeLoadException.
  • Más importante que la anterior: No nos habríamos topado con el error de haber seguido las recomendaciones de uso de DllImport. Y ni siquiera podemos alegar desconocimiento de ellas, ya que si hubiesemos usado el análisis estático de código se nos habría avisado.

En resumen, ya se ha dicho varias veces por aquí, pero el análisis estático de código es tu amigo… 🙂

Saludos!

XmlSerializer y propiedades ocultadas

Hola! Ayer un compañero de trabajo me comentó un problema con el que se encontró trabajando con propiedades ocultadas y el serializador xml.

En concreto, quería serializar dos clases tales como las que siguen:

public class FOO
{
    private List<FOO> _items;
    public List<FOO> Items
    {
        get { return _items; }
        set { _items = value; }
    }
}
public class DerivedFOO : FOO
{
    private List<DerivedFOO> _items;
    public new List<DerivedFOO> Items
    {
        get { return _items; }
        set { _items = value; }
    }
    public DerivedFOO() { Items = new List<DerivedFOO>(); }
}

Son dos clases, una que deriva de la otra, que cada una de ellas tiene una lista de elementos de la propia clase.

Al intentar serializar un objeto DerivedFOO el serializador da una excepción: “El miembro DerivedFOO.Items de tipo System.Collections.Generic.List`1[ConsoleApplication10.DerivedFOO] oculta al miembro de clase base FOO.Items de tipo System.Collections.Generic.List`1[ConsoleApplication10.FOO]. Utilice XmlElementAttribute o XmlAttributeAttribute para especificar un nombre nuevo.

La solución que propone la propia excepción (el uso de [XmlElement] o [XmlAttribute]) no funciona, y el uso de [XmlArray] tampoco.

Analicemos un poco la situación: Tenemos dos clases, una derivada de la otra, donde la derivada oculta una propiedad de la clase base. Declarar la propiedad Items como virtual y redefinirla en la clase derivada, no funciona por dos razones. La primera es que C# no acepta propiedades covariantes, lo que implica que desde una clase derivada no podemos redefinir una propiedad de la clase base para que devuelva un tipo más específico (derivado) del que declara la propiedad base. Es decir, esto no compila en C#:

class A
{
    public virtual A Self { get; set; }
}
class B : A
{
    // C# no tiene propiedades covariantes!
    public override B Self { get;set;}
}

La segunda razón por la cual, declarar la propiedad como virtual en la clase base tampoco funcionaría, es que incluso suponiendo que C# tuviese propiedades covariantes, List<FOO> y List<DerivedFOO> son dos tipos completamente distintos. Recordad que aunque B derive de A, List<B> no deriva de List<A>.

Está claro que debemos buscar otro enfoque… Una posible solución pasa por el uso de genéricos, es decir definir una sola clase base que tenga la propiedad Items, y que esta sea genérica:

public class FOOBase<T>
{
    private List<FOOBase<T>> _items;
    public List<FOOBase<T>> Items
    {
        get { return _items; }
        set { _items = value; }
    }
    public FOOBase()
    {
        Items = new List<FOOBase<T>>();
    }
}
public class FOO : FOOBase<FOO> { }
public class DerivedFOO : FOOBase<DerivedFOO> {}

En este caso definimos tres clases: La genérica FOOBase<T> que es la que contiene la definición de la propiedad, y luego dos especializaciones, que hemos llamado FOO y DerivedFOO…

Esto funciona, pero no podemos negar que hemos modificado la relación entre FOO y DerivedFOO. Inicialmente la segunda era derivada de la primera, pero ahora entre FOO y DerivedFOO no hay ninguna relación. Si queremos poder trabajar indistintamente con ambas clases (FOO y DerivedFOO) debemos trabajar a nivel de FOOBase<T>, lo que según el caso puede ser problemático:

// error CS0246: The type or namespace name 'T' could not be found
static void f(FOOBase<T> t) {}

Para que esto compile el método f debe ser a su vez genérico:

static void f<T>(FOOBase<T> t) { }

Por suerte, al menos, Visual Studio puede inferir el tipo genérico del método a partir del argumento de llamada, por lo que al menos esto funciona:

DerivedFOO df = new DerivedFOO();
f(df);

Para evitar tener que arrastrar tantos métodos genéricos es interesante tener una clase base, que no sea genérica y que defina todas las propiedades (y métodos) base que no dependen en absoluto del tipo genérico:

public class FOOBase     
{ 
    // Nueva clase base de la jerarquía
}
public class FOOBase<T> : FOOBase where T : FOOBase { private List<FOOBase<T>> _items; public new List<FOOBase<T>> Items { get { return _items; } set { _items = value; } } public FOOBase() { Items = new List<FOOBase<T>>(); } } public class FOO : FOOBase<FOO> { } public class DerivedFOO : FOOBase<DerivedFOO> {}

Ahora la clase FOOBase pasa a ser la clase principal, de la que deriva FOOBase<T>. Esto nos permite definir métodos que acepten FOOBase y que no deben ser genéricos. Evidentemente esto tiene un precio: no podemos acceder a la propiedad Items desde una referencia a FOOBase, por lo que si necesitamos acceder a esta propiedad, si que no tenemos más remedio que trabajar con métodos genéricos…

Ahora podemos serializar objetos FOO y DerivedFOO y que ambos contienen una propiedad List<T> siendo T el propio tipo, además de otras propiedades que vendrían heredades de FOOBase.

¿Satisface esto los requerimientos de mi compañero? Pues no lo sé, pero a mi no se me ha ocurrido ninguna idea más…

Saludos!

CommandPattern extendiendo Unity

Hola a todos! Hoy voy a hablar del poder que nos da el mecanismo de extensiones de Unity. Doy por supuesto que todos conoceis lo que es un contenedor IoC en general y Unity en particular. Si no, echad un vistazo a los posts “IoC o el poder de ceder el control” (para una explicación general de IoC) y “Microsoft Unity: Inyección de dependencias .NET” (para una explicación general sobre Unity en concreto).

Para ilustrar el poder que nos da extender Unity voy a poner una posible implementación del patron Command Pattern. Este patrón es un clásico para la construcción de interfaces desacopladas, donde el elemento de la UI que genera una acción y el código que implementa esta acción no tienen porque estar relacionados. Esto aumenta la mantenibilidad y la reutilización del código.

Lo que voy a exponer aquí, es una implementación de dicho patrón, usando Unity y que funciona con cualquier “tecnología” (Winforms, WPF, cónsola). Dado que esto va a ser un poco largo, coged una buena cervecita que empezamos! 😉

También comentaros que el código que mostraré, aunque funcional, no está 100% completo, pero tiene las bases para que sea fácilmente completable.

1. Extensiones de Unity… que son?

Las extensiones de Unity son el mecanismo que nos permite personalizar el comportamiento del contenedor cuando deba crear o destruir un objeto, o bien cuando se registre algún mapping entre tipos. En este post vamos a hablar de dos mecanismos para extender Unity:

  • Extensiones: Una extensión es básicamente una clase que deriva de UnityContainerExtension. Cuando se añade una extensión a Unity (cosa que puede hacerse programáticamente o por configuración), se llama al método Initialize() de la extensión. Las extensiones se usan para registrar en el contenedor nuevas Estrategias o Políticas y para suscribirnos a eventos de cuando se registra un mapping entre tipos.
  • Estrategias: Una estrategia es algo que debe hacer Unity antes o después de crear o destruir un objeto. P.ej. si colocamos un atributo [Dependency] en cualquier propiedad pública de un objeto, Unity nos rellenerá automáticamente dicha propiedad. Esto se hace a través de una estrategia (built-in dentro de Unity).

2. Unity y ObjectBuilder2

Unity en si mismo, en el fondo es simplemente, un wrapper sore ObjectBuilder2 (Una evolución del ObjectBuilder que venia con CAB y EntLib). Aunque por norma general podemos usar Unity sin preocuparnos del ObjectBuilder2 subyacente, cuando nos ponemos a extender el contenedor, entonces si que debemos interactuar con ObjectBuilder2. En concreto las estrategias se definen siempre a nivel de ObjectBuilder2, mientras que las extensiones son un mecanismo propio de Unity.

3. Nuestro modelo de Command Pattern

Para este ejemplo he pensado en un modelo de command pattern, extremadamente sencillo y declarativo (es decir, basado en atributos). Para ello vamos a usar dos atributos propios:

  • CommandSource: Para indicar que un determinado evento debe vincularse a un command.
  • CommandTarget: Para indicar que un método es la implementación de un command.

El primer atributo se define a nivel de clase (tantas veces como sea necesario), mientras que el segundo se define a nivel de método (una sola vez).

Un ejemplo de su uso:

[CommandSource("Command1", "button1", "Click")]
public partial class View1 : UserControl
{
    public View1()
    {
        InitializeComponent();
    }
}

Cuando se lance el evento “Click” del objeto “button1” se debe invocar el command “Command1”. En algún sitio habrá una clase (que no debe porque tener ninguna relación con View1) con el siguiente código para gestionar el command:

[CommandTarget("Command1")]
private void Foo()
{
    MessageBox.Show("Command1 Invocado");
}

4. Qué vamos a hacer…

Lo que queremos hacer es lo siguiente:

  • Cuando se registre un mapping en Unity, vamos a mirar la clase que se registra para inspeccionar si tiene atributos CommandSource y/o CommandTarget y vamos a guardar esta información en una clase (el CommandBroker).
  • Cuando se resuelva un tipo (es decir se cree una instancia) vamos a inspeccionar su tipo para ver si tiene atributos CommandSource y/o CommandTarget (sólo lo haremos si es necesario, que será si no se había definido un mapping para este objeto previamente), y luego nos suscribiremos a los eventos necesarios.

Así el CommandBroker es una clase que:

  • Tiene toda la información de que atributos CommandSource y/o CommandTarget tiene cada tipo creado por Unity.
  • Se suscribe a todos los eventos que vengan de un CommandSource y ejecuta el CommandTarget asociado.

El primer punto lo llevaremos a cabo mediante una extensión, y el segundo mediante una estrategia.

5. La extensión: CommandExtension

Vamos a definir nuestra extensión de Unity, para que haga tres cosas principales:

  • Cree una instancia del CommandBroker y la coloque como singleton dentro de Unity.
  • Cree la estrategia que necesitaremos y la “instale” en Unity.
  • Se registre al evento de creación de mapping para poder inspeccionar los tipos (evento Registering).

El código es realmente simple:

public class CommandExtension : UnityContainerExtension
{
    protected override void Initialize()
    {
        this.Container.RegisterInstance<ICommandBroker>(new CommandBroker());
        this.Context.Strategies.Add(new CommandStrategy(this.Container), 
            UnityBuildStage.Creation);
        this.Context.Registering += (o, e) =>
            this.Container.Resolve<ICommandBroker>().
            ProcessTypeInfo(e.TypeTo ?? e.TypeFrom);

        }
}

El método “ProcessTypeInfo” de la clase CommandBroker es la que inspecciona un tipo para ver si tiene atributos CommandSource y CommandTarget.

6. La estrategia: CommandStrategy

En la extensión creada previamente instalamos la estrategia CommandStrategy. Una estrategia se llama cada vez que Unity debe crear (BuildUp) o destruir (TearDown) un objeto.

En mi caso el código de la estrategia también es realmente simple:

class CommandStrategy : IBuilderStrategy
{
    private IUnityContainer container;
    public CommandStrategy(IUnityContainer container)
    {
        this.container = container;
    }
    #region IBuilderStrategy Members
    public void PostBuildUp(IBuilderContext context)
    {
        ICommandBroker cb = this.container.Resolve<ICommandBroker>();
        cb.ProcessObjectInfo(context.Existing);
    }
    public void PostTearDown(IBuilderContext context) { }
    public void PreBuildUp(IBuilderContext context) { }
    public void PreTearDown(IBuilderContext context) { }
    #endregion
}

En el método PostBuildUp (después de que ObjectBuilder2 haya construido el objeto) se llama a ProcessObjectInfo del CommandBroker. Este método hace dos cosas básicas:

  • Se suscribe a todos los eventos declarados en los atributos CommandSource del tipo del objeto
  • Guarda delegados a todos los métodos decorados con un CommandTarget (guardando el nombre del command asociado a cada delegado).

Así el CommandBroker se suscribirá a cualquier evento que se lance desde cualquier objeto creado por Unity, que esté referenciado por un CommandSource. Y en la función gestora de dicho evento mirará en su tabla interna de delegados  si hay alguno que pueda responder a dicho evento (basándose en el nombre del comando).

Si observais el constructor de la CommandStrategy, vereis que recibe una instancia del propio Unity. Esto es para poder obtener el CommandBroker, puesto que en la extensión lo registrábamos como singleton en Unity. Esto puede parecer sorprendente (que desde una estrategia de Unity no se tenga acceso al propio Unity)… es lo que decía antes que las estrategias se definen a nivel de ObjectBuilder2.

7. El código…

No comento más el resto del código, puesto que sólo conseguiria liar el post. Para los interesados lo dejo todo en un zip: UnityExtensions.zip. El código está comentado para que sea fácilmente entendible. Destacar que las clases que hacen el trabajo pesado son CommandTypeDescriptor (que es quien realmente mira todos los [CommandSource] y [CommandTarget], CommandInfo (que mantiene toda la información de UN comando) y el propio CommandBroker.

Como he dicho el código NO está del todo completo, p.ej. si se registra un singleton con RegisterInstance, dicho singleton no participa del sistema de comandos, y luego en ningún caso el CommandBroker se “desuscribe” a ningún evento. También para que fuese una implementación completa del patrón CommandPattern, se debería poder (de alguna manera) activar o desactivar comandos. Al desactivar un comando todos los elementos de la UI vinculados a él (o sea todos sus [CommandSource]) deberían deshabilitarse

… pero bueno, todo es meterse! 😉

Espero que este post os haya dado una idea del potencial de extender Unity (y también del patron Command Pattern”).

Saludos!

Strings en .NET y el BOM

¿Conoceis el BOM? Los que no, teneis suerte… los que sí, seguro que lo habeis sufrido… 🙂 Para los que no, contaros que el BOM, o Byte Order Mask que es lo que significan sus siglas, no es nada más que una marca (de entre 2 y 3 bytes) al principio de un archivo Unicode que indica el formato de los datos… si están en little endian o big endian p.ej.

Quereis verlo en acción? Abrid el bloc de notas y teclead cualquier palabra, como p.ej. Agüero (algún fan del atleti por aqui???). Ahora haced un “guardar como” y marcad la opción “Unicode big endian” en codificación.

Ahora si miramos el tamaño del archivo, vereis que ocupa 14 bytes… Las cuentas no salen: Agüero tiene 6 letras, a 2 bytes la letra Unicode… sobran 2 bytes. El BOM. ¿Queréis más pruebas? Haced un type del archivo desde una consola. Vereis algo como:

■  A g ³ e r o

Este “cuadradito negro” que aparece al principio es el BOM. Que pasa si os lo cargais??? Si abris el fichero con un editor hexadecimal (como el mismo Visual Studio) vereis algo como:

FE FF 00 41 00 67 00 FC 00 65 00 72 00 6F   …A.g…e.r.o

Los dos primeros bytes (FE FF) son el BOM… borradlos para que vuestro archivo quede tal como:

00 41 00 67 00 FC 00 65 00 72 00 6F   .A.g…e.r.o

Lo guardais de nuevo y lo abrís con el bloc de notas… y esto es lo que vereis:

A g ü e r o

Sin BOM el bloc de notas identifica este archivo de texto como ANSI en lugar de Unicode, e interpreta el byte 00 de cada carácter Unicode como un carácter ANSI adicional.

¿Divertido, eh? Pues no os digo nada cuando uno se encuentra que según el protocolo o producto que use el BOM puede ser opcional, obligatorio o hasta prohibido…

¿Y porque os cuento todo esto? Pues porque me he encontrado con un comportamiento curioso (no digo ni que esté mal ni que esté bien) con las strings de .NET y el BOM. Tengo el siguiente código:

class Program
{
    static void Main(string[] args)
    {
        string foo = (char)0xfeff + "Foo";
    }
}

Fácil, eh? Creo una string y le añado el BOM al principio… Y ahora viene lo curioso:

  1. foo.Length devuelve 4 porque cuenta el BOM como un carácter más
  2. foo[0] es un carácter con valor 0xfeff
  3. foo[1] es un carácter con valor 0x0046 (‘F’)
  4. foo.StartsWith(foo[0] + “”) devuelve true, indicando que la cadena empieza con el BOM
  5. foo.StartsWith(foo[1] + “”) también devuelve true, indicando que la cadena empieza por “F”
  6. foo.Equals(foo.Substring(1)) devuelve false, indicando que ambas cadenas son distintas
  7. foo.CompareTo(foo.Substring(1)) devuelve 0, indicando que ambas cadenas son iguales
  8. foo.Trim se carga el BOM (o sea foo.Trim().Length vale 3)

En fin… parece ser que algunos métodos conocen el BOM y lo ignoran y otros no y lo tratan como un caracter más…

¿Curioso, no?

Unity? Sí gracias, pero no me abraces demasiado…

No hace mucho, Jorge Dieguez escribió un interesante post sobre Unity y el patrón de Dependency Injection. Resumiendo mucho este patrón permite eliminar las dependencias de nuestro código, trasladandolas todas a un sólo elemento, que se conoce generalmente como “contenedor de DI”. Este contenedor es el responsable de devolvernos todas las referencias a clases que nostros precisemos.

Las ventajas es que tenemos un código mucho menos acoplado, que por lo tanto es más fácil de probar y de mantener.

Contenedores de DI hay muchos, p.ej. en .NET tenemos a Unity (que viene de la mano de la gente de P&P) a Windsor Container o a Spring.NET sólo por citar tres ejemplos. Cada uno de ellos (y de los muchos otros que hay) tienen sus características y peculiaridades y dado que estamos pensando en hacer código débilmente acoplado… quizá deberíamos evitar ligarnos a nuestro contenedor DI, porque nunca sabemos cuando nos puede interesar cambiar.

Cojamos el caso de Unity. Imaginemos el siguiente proyecto super sencillo:

namespace UnityTest
{
    interface IFoo {}
    class FooClass : IFoo { }
    class Program
    {
        static void Main(string[] args)
        {
            UnityContainer uc = new UnityContainer();
            uc.RegisterType<IFoo, FooClass>();
            IFoo foo = uc.Resolve<IFoo>();
            Console.WriteLine(foo.GetType().FullName);
            Console.ReadLine();
        }
    }
}

Es una aplicación de consola, donde se declara una interfaz (IFoo), una clase que la implementa (FooClass) y luego en el método Main:

  1. Se crea una instancia de Unity
  2. Se registra el mapping entre IFoo y FooClass
  3. Se obtiene una instancia de IFoo.
  4. Miramos el tipo de la referencia obtenida

Como os podeis suponer lo que este programa muestra por pantalla es: UnityTest.FooClass

Unity nos devuelve una instancia de FooClass cada vez que le pedimos una instancia de IFoo, porque así lo especifica el mapping creado con RegisterType.

Hasta ahora todo perfecto: nuestra interfaz IFoo y nuestra clase FooClass no estan ligadas a Unity en ningún modo… vamos a ver como se nos pueden torcer las cosas…

Modificamos la clase FooClass para que tenga dos constructores:

class FooClass : IFoo 
{
    public FooClass() 
    { 
        Console.WriteLine("FooClass::Default ctor"); 
    }
    public FooClass(BarClass bar) 
    { 
        Console.WriteLine("FooClass::Bar ctor"); 
    }
}

El resto del código es igual que antes, con la excepción de que nos aparece una clase nueva (BarClass) que da igual (puede ser vacía, no nos afecta). La pregunta es obvia: ¿que constructor usará Unity para construir un objeto FooClass?

La respuesta es: el que tenga el mayor número de parámetros (¿la razón? Quien sabe…). Unity utilizará el constructor con mayor número de parámetros e inyectará todos los parámetros (llamando internamente al método Resolve) a dicho constructor. ¡Eh, un momento! Esto está muy bien pero… nosotros no hemos definido ningún mapping para BarClass en Unity… ¿No debería quejarse? Pues no: El método Resolve<T> de Unity es capaz de crear cualquier clase para que lo no haya un mapping definido, siempre y cuando T sea una clase, no una interfaz.

Si alguien se pregunta que pasaría si FooClass tuviese dos constructores con un parámetro, entonces Unity se quejará con una excepción parecida a: The type FooClass has multiple constructors of length 1. Unable to disambiguate.

Supongamos que queremos que Unity use un constructor en concreto (bien sea porque tenemos varios constructores con mayor número de parámetros o bien porque queremos usar alguno en concreto). En este caso, una solución es aplicar el atributo InjectionConstructor al constructor que queramos que use Unity:

class FooClass : IFoo 
{
    [InjectionConstructor]
    public FooClass() 
    { 
        Console.WriteLine("FooClass::Default ctor"); 
    }
    public FooClass(BarClass bar) 
    { 
        Console.WriteLine("FooClass::Bar ctor"); 
    }
}

Bueno… esto funciona correctamente, pero en este momento hemos creado una dependencia entre FooClass y Unity. Si algluna vez nos cambiamos a cualquier otro conenedor de DI, no podemos esperar que entienda el atributo InjectionConstructor, ya que éste, obviamente, es propio de Unity. Así que ahora nuestro código está acoplado a Unity… lo cual no es la solución ideal (en algunos casos).

Por suerte existe una solución que nos permite que nuestra clase FooClass no tenga dependencias contra Unity: cuando especificamos el mapping podemos indicarle que constructor utilizar. Para ello podemos usar el método Configure de Unity:

uc.RegisterType<IFoo, FooClass>().Configure<InjectedMembers>().
    ConfigureInjectionFor<FooClass>(new InjectionConstructor());

Aquí estamos registrando el mapping entre IFoo y FooClass, y configuramos los miembros inyectados para el tipo FooClass para que use el constructor sin parámetros. Si quisieramos usar el constructor con un parámetro BarClass:

uc.RegisterType<IFoo, FooClass>().Configure<InjectedMembers>().
    ConfigureInjectionFor<FooClass>(
    new InjectionConstructor(new BarClass()));

Con esto Unity cada vez que deba crear un FooClass, usará el constructor que acepta un parámetro BarClass y lo invocará con una instancia de BarClass.  Unity usará siempre la misma instancia de BarClass para todos los FooClass que cree. Es decir, si tenemos:

IFoo foo = uc.Resolve<IFoo>();
IFoo foo2 = uc.Resolve<IFoo>();

Tanto foo como foo2 serán creados con el constructor que acepta un BarClass pero el BarClass que ambos reciban será el mismo. Incluso aunque no creemos ningún objeto FooClass, el objeto BarClass sí que se crea.

Si queremos que Unity cree cada vez un BarClass para cada FooClass, entonces podemos utilizar el siguiente código:

uc.RegisterType<IFoo, FooClass>().Configure<InjectedMembers>().
    ConfigureInjectionFor<FooClass>(
    new InjectionConstructor(typeof(BarClass)));

En este caso, Unity creará un BarClass nuevo cada vez que deba crear un FooClass… Bueno, esto no es estrictamente cierto: Realmente Unity cada vez llamará a su método Resolve<BarClass>, cada vez que deba obtener un BarClass para llamar al constructor de FooClass. Si no tenemos mapping definido, Resolve<BarClass> crea un BarClass nuevo cada vez. Pero, si definiesemos el siguiente mapping:

uc.RegisterInstance<BarClass>(new BarClass());

Aquí estamos registrando una instancia de BarClass como singleton dentro de Unity. Por lo tanto todas las llamadas a Resolve<BarClass> devolverán el mismo objeto… volvemos a la situación anterior: todos los constructores de FooClass recibirán el mismo BarClass. E igual que antes el BarClass se crea cuando se llama a RegisterInstance, por lo que aunque no creemos ningún FooClass, el BarClass sí que es creado.

Tenemos una variación de este caso. Si registramos BarClass como singleton, usando RegisterType:

uc.RegisterType<BarClass>(new ContainerControlledLifetimeManager());

Ahora BarClass está registrado como singleton,  pero no se creará la primera instancia de BarClass hasta que sea necesario. Así, cuando creemos el primer FooClass, Unity creará el BarClass y lo usará como parámetro del constructor. Para crear el segundo FooClass, Unity usará el BarClass previamente creado.

Pero lo importante es que nuestra clase FooClass no depende para nada de Unity, de forma que podemos reutilizarla en cualquier otro proyecto o bien cambiar de contenedor de DI… Que sí, que Unity está muy bien pero tampoco es plan de que nos atemos a él, no????

Saludos!