Definiendo la arquitectura base de nuestro proyecto

Actualización Febrero 2014: La arquitectura propuesta aquí se refino en el post numero 10 de la serie.

Continuando con nuestro desarrollo, después de pensar un rato en esto, terminé la definición de la distribución de componentes según sus responsabilidades dentro de mi solución. Mi decisión fue no usar controles de terceros y evitar al máximo usar frameworks o librerias externas, con excepcion de SQLite y el Toolkit de Windows Phone, vamos a ver como nos va con esa decisión.

La solución quedó estructurada de la siguiente manera:

Para entender mejor la relación entre los proyectos, les dejo un diagrama de paquetes. Allí se puede observar donde quedaron los modelos que usaremos para consumir los datos vía Json como se explicó en otro post y también las Vistas Modelo que definimos en el post antenior.

* El diagrama está actualizado al 15 de Diciembre con el post 9.

Como ven, el trabajo que tenemos es bastante, aun no se si nos mantedremos así hasta el final, pero lo intentaremos.

Como pueden observar quiero en este ejercicio lograr que la clase de infraestructura sea lo más reutilizable posible, por lo que aprendiendo del mejor maestro Josue Yeray y sus ejemplos, tengo varias clases reusables, incluida una implementación de un Service Locator, que no usa frameworks externos, espero que cuando empecemos la app de Android y iPhone el hecho de no usar más que código C# nos traiga grandes ventanas.

A veces tiendo a exagerar con la separación por assemblies pero les aseguro que estuve pensando en esto un buen rato y por el momento estoy conforme, las librerías todas son portables con este soporte:

Si necesitas conocer que es una Librería Portable (PCL) sus ventajas y limintaciones en MSDN encuentras la explicación en español. Los demás proyectos son una aplicación panorama Windows Phone 8, una aplicación Hub Windows 8, y un proyecto de Test.

No olviden que para entender las decisiones de esta estructura deben tener idea y conceptos al menos básicos de XAML y MVVM razón por la que nuevamente les comparto la diapositiva de intro y no se olviden de ver la explicación en video de Josue Yeray del patrón MVVM.

Ahora, si bien esa es la estructura de nuestra solución, vale la pena detenernos en esas 3 clases en particular de infraestructura, que con suerte son las que nos van a ayudar a trabajar una buena aplicación cross platform, puede que no de la manera más óptima pero si de la más transparente y bajo nuestro control.

La primer clase es BindableBase, tomada tal cual de la plantilla de Windows 8, y adecuada con el Service Locator, es la clase que va a permitir a nuestras Vistas Modelos ser escuchadas por las Vistas cuando realicen un cambio, todo gracias a INotifyPropertyChanged.

La segunda clase interesante es el DelegateCommand en su implementación seguro más sencilla, nos va a permitir enlazar comandos de nuestras Vistas Modelos con nuestras Vistas sin usar Code Behind.

La última pero no menos importante es la clase ServiceLocator que nos permitirá obtener las instancias de las clases que son el contexto de nuestra aplicación desacoplando las vistas de estas clases y a la vez de facilitándonos hacer TestCases pues también tendrá una referencia a los servicios que usamos siempre disponible.

Mi lectura recomendada está en MSDN, aunque no está en contexto de apps móviles de manera general explican el patrón Services Locator.

El Service Locator es una versión especializada del patrón de Inversión de Control (IoC). La inyección de dependencias resuelve el mismo problema que el Service Locator pero usa una implementación diferente, para hacer inyección de dependencias podemos usar componentes como Unity que está disponible vía Nuget para nuestras aplicaciones de forma gratuita y que es provisto por Microsoft Patterns and Practices.

Como ven, las clases descritas cumplen propósitos generales, y si todo sale bien sencillamente podrían ser usadas tal cual en otras aplicaciones.

Actualización 11 de Diciembre: Lo más bonito del conocimiento es cuando se multiplica, les comparto la explicación de Emerson Perdomo sobre Inversion de Control e Inyección de Dependencias. Mil gracias por compartirlo :)

Nota: Veo que este post ha tenido muchas visitas, y no tanto así el de pruebas unitarias, mi invitación es a que se pasen por allá tambien, puesto que al intentar crear las pruebas unitarias para congreso visible, se añadieron más cosas a la arquitectura que deben ser entendidas y tomadas en cuenta.

Actualización 15 de Diciembre: En el post 9 este era nuestro diagrama de dependencias, para entenderlo no pueden olvidar seguir la serie de Congreso Visible para ver de que manera evolucionamos hasta aquí. La parte negativa y a la vez positiva de todo esto es que al hacer este análisis logré identificar que algo estaba mal.

Como pueden ver, el proyecto de insfraestructura tiene una relacion indeseada con Congreso Visible ¿Por qué indeseada? pues bien este proyecto debia ser transportable a otros proyectos sin ser tocado, así que en este punto entre a resolver la situación. Quitando los proyectos de test el nuevo diagrama luce asi:

El cambio interno fue que las interfaces que necesitaban de infraestructura se movieron a ese proyecto y fue bastante transparente, es decir, nuestro proyecto de infraestructura quedaría asi:

* He actualizado el diagrama de paquetes del inicio de este post a la fecha.