Blog de Fernando Machado Piriz

Artículos sobre arquitectura corporativa y temas relacionados

Posts Tagged ‘C# 4.0

Primera beta de Microsoft Visual Studio LightSwitch

with 8 comments

Un nuevo miembro de la familia de herramientas para desarrolladores fue anunciado a comienzos de este mes y la primera versión beta estará disponible para descarga a partir del 23 de agosto: Microsoft Visual Studio LightSwitch.

¿Qué es y para qué sirve?

LightSwitch permite crear fácil y rápidamente aplicaciones de negocio completas desde cero, incluyendo no sólo los formularios de la interfaz de usuario, sino también la base de datos; también permite crear aplicaciones a partir de bases de datos existentes.

En este artículo voy a dar un rápido paseo sobre LightSwitch usando la versión beta que estará disponible en breve. Lo que voy a crear es una aplicación muy simple para registrar los libros que presto a mis amigos.

Una nueva aplicación con LightSwitch comienza con la creación de un nuevo proyecto en Visual Studio. Un proyecto LightSwitch va a contener la definición de los datos y de los formularios de la aplicación. A partir de esas definiciones LightSwitch genera la base de datos en SQL Server y el código fuente de la aplicación en C# o Visual Basic.

En este artículo voy a usar la plantilla de proyecto de C#. Aquí pueden ver el familiar cuadro de diálogo para la creación de un nuevo proyecto en Visual Studio con las dos plantillas provistas por LightSwitch.

image

Una vez creado el proyecto podemos conectarnos a una fuente de datos existente o crear una nueva definición de los datos de la aplicación. En este artículo voy a mostrarles cómo crear la definición de los datos desde cero.

image

La primera definición es la de los libros. De cada libro me interesa el autor y el título. Creo una entidad Book, con campos Author y Title, ambos de tipo String y ambos requeridos. Estas entidades estarán almacenadas en una tabla Books.

image

Luego creo la definición de los préstamos. De cada préstamo me interesa saber a quién se lo presté, cuándo lo presté y cuándo me lo devolvieron. Creo entonces una segunda entidad Loan, con campos ToFriend, DateLoaned y DateReturned; el primero es de tipo String y los otros dos de tipo Date; los dos primeros son requeridos, no así el último. Estas entidades estarán almacenadas en una tabla Loans.

image

Ahora defino una nueva relación entre libros y préstamos.

image

Vean a continuación cómo queda la definición de la entidad Loan y su relación con Book.

image

Ahora debo definir los formularios para editar estas entidades. Varias plantillas de formularios están disponibles -para editar los registros de a uno, en una grilla, etc.-. Voy a usar la plantilla para un formulario simple de altas.

image

La definición del formulario puede ser modificada. Lo que he cambiado es solamente el nombre a mostrar y la descripción.

image

Una vez terminada la definición, puedo probar la aplicación. Esta versión de LightSwitch permite generar los siguientes tres tipos de aplicaciones:

image

Al hacer el build LightSwitch:

  • Crea la base de datos
  • Genera el código fuente
  • Compila el código de la aplicación

Una aplicación LightSwitch típicamente es una aplicación en tres capas, que usa ciertas tecnologías específicas para cada una de ellas:

  • La capa de presentación, responsable de la edición y presentación de los datos, es una aplicación Silverlight 4.0
  • La capa de lógica de negocio, responsable de las consultas, actualizaciones, validaciones y procesamiento de datos, y expone un conjunto de WCF RIA Domain Services corriendo en ASP.NET 4.0 sobre IIS o un Windows Azure web role.
  • La capa de datos, responsable de almacenar los datos, usa SQL Server o SQL Azure.

En este artículo –en inglés- pueden encontrar más información sobre la arquitectura de una aplicación LightSwitch.

Al ejecutar la aplicación LightSwitch

  • Levanta un web server local
  • Despliega la aplicación en ese web server
  • Abre la aplicación

Esto es lo que vemos:

image

Completamos los campos para agregar el primer libro:

image

La aplicación asigna automáticamente un identificador al primer libro:

image

La aplicación incluye out of the box algunas validaciones elementales, como las de los campos que están marcados como requeridos.

image

image

image

El segundo formulario es el de alta de préstamos. También es un formulario simple de altas. Podemos ver como LightSwitch asignó un control Date Picker a los campos DateLoaned y DateReturned, que son de tipo Date. También asignó un control de tipo Modal Window Picker para editar la asociación entre Loan y Book.

image

Al ejecutar la aplicación podemos ver cómo luce el control asignado automáticamente a los campos de tipo Date.

image

El control Modal Window Picker permite buscar y seleccionar un libro para asociar con este préstamo. El control incluye funciones de búsqueda y paginado de los resultados.

image

Aunque esta forma de editar los préstamos no está mal, preferiría poder ver la lista de libros y desde allí fácilmente acceder a los préstamos de cada libro y eventualmente agregar nuevos préstamos también desde allí. La plantilla para este tipo de mantenimiento es List and Details Screen. Vean cómo LightSwitch me permite indicar si quiero incluir los detalles de los libros y de los préstamos en el mismo formulario.

image

Una vez creado el formulario puedo editar su definición. Al igual que en los casos anteriores, sólo cambio ligeramente el nombre a mostrar sugerido y agrego una descripción.

image

Podemos ver cómo luce este nuevo formulario al ejecutar la aplicación. La lista de libros aparece a la izquierda. Desde allí puedo agregar, modificar y eliminar libros. Para el libro seleccionado en la lista de la izquierda, puedo ver los préstamos en la parte derecha. También aquí puedo agregar, modificar y eliminar préstamos.

image

Vean que para agregar y modificar libros y préstamos LightSwitch generó automáticamente un formulario con los mismos controles que definí antes en los respectivos formularios para dar de alta estas entidades.

image

image

Estos formularios también tienen el comportamiento para las validaciones definidas en las entidades.

image

El editar más de una entidad en una lista, las modificaciones son impactadas en la base de datos al guardar la lista y no cada entidad.

image

¿Cuánto me llevó hacer todo esto? No mucho, vean el siguiente video:

Pueden descargar el video desde aquí.

Todo esto está muy bien, pero ¿qué aplicaciones puedo hacer con LightSwitch? Probablemente haya que esperar un tiempo para ver realmente quiénes pueden aprovechar esta nueva tecnología. Aplicaciones simples como la del ejemplo pueden ser creadas muy rápidamente, pero todos sabemos que las aplicaciones del mundo real nunca son tan fáciles como las de las demos, ¿verdad? Para los desarrolladores ocasionales o no profesionales -para quienes en su momento fueron pensadas cosas como Microsoft Access o Visual FoxPro- LightSwitch puede ser su nueva herramienta. Los desarrolladores profesionales probablemente no puedan construir con LightSwitch el 100% de las complejas aplicaciones de negocios que crean hoy en día. Pero aún ellos pueden al menos usar LightSwitch como herramienta para la creación de prototipos rápidamente.

En ciertos lugares de la definición de la aplicación puedo escribir código C# para agregar aquellas funcionalidades no contempladas inicialmente por LightSwitch -para las reglas de negocio por ejemplo-. Pero entonces tengo que conocer el modelo de objetos generado por LightSwitch, para poder consumir desde mi código escrito a mano los tipos generados automáticamente.

Algunas de las plantillas parecen extensibles –hoy algunas listas de plantillas tienen un solo elemento, pero probablemente se deba a que se trata de una versión beta-. Además, parece que LightSwitch podrá generar aplicaciones también para Windows Azure. Desde que todo el código y la base de datos son generados a partir de las definiciones, la misma aplicación podría ser migrada desde el escritorio a la nube con sólo cambiar una opción en las propiedades del proyecto.

Con un modelo de objetos fácil de consumir en los puntos de extensión y un ecosistema fuerte aumentando las capacidades de LightSwitch, es probable que podamos usarlo para desarrollar aplicaciones no tan triviales como las del ejemplo. Es muy pronto todavía, el tiempo lo dirá.

Written by fernandomachadopiriz

19/08/2010 at 19:56

El nuevo Visualization and Modeling Feature Pack permite generar diagramas UML a partir del código y viceversa

leave a comment »

Microsoft publicó reciente el Visualization and Modeling Feature Pack para Visual Studio 2010. La descarga está disponible para suscriptores de MSDN aquí. Incluye las (largamente esperadas) características siguientes:

  • Generación de código a partir de diagramas UML.
  • Generación de diagramas UML desde el código.
  • Importar elementos de modelos de clase, secuencia, y casos de uso UML desde archivos XMI 2.1.
  • Crear y ver vínculos desde work items a elementos de los modelos.
  • Generar grafos de dependencias desde proyectos web ASP .NET, C y C++.
  • Crear y validar diagramas de capas para código C y C++.
  • Escribir código personalizado para crear, modificar y validar diagramas de capas.

El siguiente diagrama de clases UML de Giving a Presentation fue creado usando el Visualization and Modeling Feature Pack en cuestión de un par de minutos:

ClassDiagram

¿Reconocen cómo fue usado el patrón Model View View Model? Es fácil a partir del diagrama, ¿no?

Written by fernandomachadopiriz

16/06/2010 at 18:25

Una introducción simple al patrón Model View ViewModel para construir aplicaciones Silverlight y Windows Presentation Foundation

with 9 comments

Hace algún tiempo estuve buscando una introducción simple al patrón Model View ViewModel (también conocido como MVVM) y todos los ejemplos que encontré eran un poco complicados para mi gusto. En este artículo trataré de presentarles el patrón MVVM usando el ejemplo más simple posible, enfocándome solo en los conceptos clave de MVVM. En otros artículos entraré en detalle de conceptos relacionados, pero vamos a comenzar con lo básico.

MVVM es un sucesor de otro patrón bien conocido y exitoso como es el Model View Controller (MVC). MVC nació (como tantos otros patrones bien conocidos y exitosos) en el mundo de Smalltalk hace más de treinta años. Al usar MVC la aplicación se compone de tres tipos de objetos, con responsabilidades bien claras y diferenciadas:

  • El modelo. Habitualmente hay un solo modelo por aplicación. El modelo es responsable de todos los datos de la aplicación y de la lógica de negocios relacionada.
  • La vista o vistas. Una o más representaciones para el usuario final del modelo de la aplicación. La vista es responsable de mostrar los datos al usuario y de permitir la manipulación de los datos de la aplicación.
  • El controlador o controladores. Habitualmente hay un controlador por vista, aunque no es raro ver un controlador por entidad de dominio controlando varias vistas. El controlador es responsable de transferir datos desde el modelo hacia la vista asociada y viceversa. También es responsable de implementar el comportamiento de la vista para responder a las acciones de los usuarios.

image

Con MVC cada tipo de objeto es responsable de solo una cosa, lo que simplifica el desarrollo, comprensión y prueba del código. Además, es fácil reemplazar las vistas, o tener más de una vista de los mismos datos.

En el caso de las aplicaciones Silverlight o Windows Presentation Foundation (WPF/SL), el .NET Framework provee la capacidad de usar bindings para transferir datos desde y hacia la vista, por lo que el controlador solo es responsable de implementar el comportamiento de la vista. En este caso, el controlador es llamado modelo-vista (view model), dando origen al patrón MVVM:

  • El modelo. Lo mismo que en MVC.
  • La vista o vistas. Igual que en MVC.
  • El modelo-vista. Uno o más por vista. El modelo-vista es responsable de implementar el comportamiento de la vista para responder a las acciones del usuario y de exponer los datos del modelo de forma tal que sea fácil usar bindings en la vista.

image

MVVM comparte todos los beneficios de MVC, pero tiene un beneficio adicional: la simplificación que resulta de usar binding declarativo para transferir los datos desde y hacia el modelo a la vista.

Voy a mostrar cómo funciona MVVM con un ejemplo. El código que voy a estar usando es de mi aplicación de ejemplo Giving a Presentation (aunque los animo a descargar el archivo de instalación y el código fuente de CodePlex, no hay necesidad de hacerlo para entender este artículo).

Giving a Presentation es una simple aplicación para cambiar ciertas configuraciones del equipo mientras damos una presentación, por ejemplo, ocultar los íconos del escritorio, remover o reemplazar el fondo del escritorio, etc. Los cambios son deshechos cuando la presentación termina.

La capacidad para cambiar estas configuraciones es provista por partes extensibles y no está implementada en la propia aplicación (más detalles en este artículo). Por lo tanto, siendo estrictos, los datos que maneja Giving a Presentation son solo un valor lógico que indica si el usuario está dando una presentación o no: el usuario asigna el valor en verdadero cuando comienza la presentación y lo vuelve a falso cuando la presentación termina.

El código del modelo aparece a continuación. Como prometí, es muy simple; sólo tiene una propiedad lógica:

public class Model
{
    public bool GivingAPresentation { get; set; }
}

He aquí el código del modelo-vista. También es muy simple. Como el modelo, sólo tiene una propiedad lógica, cuyo valor se obtiene de una instancia del modelo:

public class MainViewModel
{
    private Model model;
    public bool GivingAPresentation
    {
        get { return model.GivingAPresentation; }
        set
        {
            model.GivingAPresentation = value;
        }
    }

    public MainViewModel()
    {
        this.model = new Model();
    }
}

La vista (sin ninguna extensión) luce así:

clip_image006

El código XAML correspondiente es:

<Window x:Class="GivingAPresentation.MainView"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        xmlns:vm="clr-namespace:GivingAPresentation "
        Title="Giving a Presentation" Height="350" Width="525" Icon="/MvvmDemo;component/Images/Presentation.ico">
    <Window.Resources>
        <vm:MainViewModel x:Key="mainViewModel"/>
    </Window.Resources>
    <Grid>
        <CheckBox Content="I'm currently giving a presentation"
                  HorizontalAlignment="Left" VerticalAlignment="Top" Margin="12,12,0,0"
                  IsChecked="{Binding Source={StaticResource mainViewModel}, Mode=TwoWay, Path=GivingAPresentation}" />
    </Grid>
</Window>

Es interesante mencionar que no hay code-behind para esta vista [1] (es más, he borrado el archivo MainView.xml.cs del proyecto, y obviamente la solución compila y la aplicación ejecuta perfectamente). ¿Se preguntan por qué? Porque no hay necesidad de ningún código en el code-behind de la clase; el comportamiento de la vista está programado en el modelo-vista, no en la vista, ¿recuerdan?

La vista está conectada con el modelo en tres pasos. Primero, un atributo xmlns en el nodo Window es usado para crear un alias vm al espacio de nombres GivingAPresentation con xmlns:vm=”clr-namespace:GivingAPresentation. Luego, una instancia del modelo-vista es creada en el nodo Window.Resources; el nombre de esta instancia es declarado con x:Key=”mainViewModel”. Finalmente la propiedad IsChecked de la casilla de verificación de la vista es bindeada con la propiedad GivingAPresentation del modelo-vista con IsChecked=”{Binding Source={StaticResource mainViewModel}, Mode=TwoWay, Path=GivingAPresentation}”.

Y eso es todo. WPF/SL hacen la magia de obtener el estado de la casilla de verificación del valor de la propiedad del modelo-vista, quién a su vez lo obtiene de la propiedad correspondiente del modelo. A través de esta cadena, un cambio en la vista se refleja en el modelo y viceversa.

Este ejemplo es tal vez demasiado simple, pero tiene todos los componentes del patrón MVVM, y muestra claramente los fundamentos para implementar aplicaciones WPF/SL usando ese patrón.

¿Qué sigue? Hay varias cosas, muy comunes en escenarios de aplicaciones del mundo real, que no están resueltas en absoluto en este ejemplo tan simple; por ejemplo:

  1. No sólo la vista, sino probablemente otros objetos, necesiten estar al tanto de los cambios en las propiedades del modelo-vista. Aquí es donde entra en juego la interfaz INotifyPropertyChanged. Al disparar un evento PropertyChanged cada vez que cambia el valor de una propiedad, otros objetos pueden reaccionar a esos cambios. Vale la pena mencionar que estos otros objetos no son conocidos por el modelo-vista, pero son notificados de todas formas, gracias a la infraestructura de eventos del .NET Framework.
  2. Es muy común que la vista pida al modelo-vista que ejecute ciertas acciones. Esto se puede lograr si el modelo-vista expone comandos, y la vista usa bindings para ciertas acciones (como el clic de un botón) a esos comandos.
  3. También es muy común que las aplicaciones de la vida real tengan varias vistas interdependientes que necesitan comunicarse entre ellas. Para mantener estas vistas, y sus modelos-vista asociados, independientes unos de otros, los modelos-vista pueden usar mensajes para comunicarse entre ellos.
  4. ¿Quién crea a quién? En este ejemplo la vista crea declarativamente el modelo-vista (en el código XAML de la vista), y el modelo-vista crea el modelo. En aplicaciones más grandes, este enfoque no siempre es adecuado, y son necesarias otras clases para manejar la creación de objetos.

Estos aspectos no son realmente parte del patrón MVVM, pero son realmente necesarios para implementar aplicaciones del mundo real usando WPF/SL; es por es que pueden verlos junto con el patrón MVVM en la literatura. Planeo cubrir estos temas en futuros artículos y no en este, para mantener esta simple introducción, simple.

Espero hayan disfrutado de la explicación. Espero verlos pronto. Adiós.


[1] En este ejemplo. En el código real de Giving a Presentation, el vista es responsable de tareas relacionadas con la presentación, como mostrar el ícono de notificación cuando se minimiza por ejemplo, que require code-behind en la vista.

Written by fernandomachadopiriz

09/06/2010 at 23:03

¿Das presentaciones frecuentemente? Mira esto

with 3 comments

Para usuarios finales: Giving a Presentation es una aplicación simple para cambiar ciertas configuraciones del equipo mientras damos una presentación, por ejemplo, ocultar los íconos del escritorio, inhabilitar el protector de pantalla, cerrar ciertos programas, etc. Los cambios son deshechos cuando la presentación termina. Inicialment construida como un ejemplo para mostrar ciertas tecnologías, la aplicación se volvió útil por sí misma.

Miren este video para ver cómo funciona Giving a Presentation:

Si quieren probar Giving a Presentation por ustedes mismos, pueden descargar los archivos de instalación desde Codeplex.

Para desarrolladores: Giving a Presentation es una aplicación WPF de ejemplo creada en C# que uso como ejemplo en algunos artículos sobre Managed Extensibility Framework, Dependency Injection and Inversion of Control, etc. que escribo en este blog. Demuestra cómo construir una aplicación extensible formada por un contenedor de partes que lo componen.

En esta aplicación de ejemplo, el contenedor es la ventana printicpal, más el tab control en ella. El tab control tiene solo una tab Default y otra About. La tab Default está inicialmente vacía; va a ser completada dinámicamente con las partes componentes.

La tab About muestra la información típica sobre la versión de la aplicación, etc.

Las partes componentes son clases que necesitan cumplir tres requisitos:

  1. Deben implementar una interfaz GivingAPresentation.Common.Contract.
  2. Deben estar decoradas con el atributo Export de System.ComponentModel.Composition.
  3. Deben ser distribuidas en un ensamblado en la misma carpeta que el contenedor.

El Managed Extensibility Framework y la clase MainWindow de la aplicación hacen el resto. El primero carga en una lista instancias de todos los tipos exportados que implementan la interfaz requerida mencionada. El segundo toma las instancias de la lista y agrega los controles en el tab apropiado del tab control.

Hasta ahora he creado cuatro partes componentes para resolver algunos de los problemas típicos que aparecen cuando damos una presentación:

  • Ocultar los íconos del escritorio. Habitualmente ponemos documentos en el escritorio. Algunos de esos documentos son privados y no queremos que la audiencia los vea antes que proyectemos nuestra presentación. Usando esta característica es posible ocultar los íconos del escritorio durante una presentación y mostrarlos nuevamente al final.
  • Inhabilitar el protector de pantalla. Podemos tener el protector de pantalla configurado para iniciar luego de cierto tiempo de inactividad. Si pasamos mucho tiempo en la misma diapositiva durante una presentación, el protector de pantalla puede interrumpir la presentación. Usando esta característica es posible inhabilitar el protector de pantalla durante la presentación y habilitarlo nuevamente al final.
  • Cerrar programas. Algunos programas muestran ventanas de notificación, por ejemplo, los clientes de correo electrónico o mensajería instantánea. Más allá de la interrupción, el contenido de la notificación puede ser inapropiado para que la audiencia lo vea durante nuestra presentación. Usando esta característica es posible cerrar programas que se seleccionen, e iniciarlos nuevamente al finalizar la presentación.
  • Cambiar u borrar el fondo de pantalla. ¿No sería genial poder cambiar el fondo de pantalla con el logo de nuestra empresa o con el logo del evento en el que estamos presentando para que la audiencia lo vea mientras no estamos proyectando la presentación? Usando esta característica es posible reemplazar la imagen del fondo de pantalla por una seleccionada o remover la imagen del fondo durante una presentación, volviendo todo a como esta inicialmente al finalizar.

Miren este video para ver cómo estas partes efectivamente extienden el contenedor dinámicamente:

También pueden descargar el código fuente de Giving a Presentation desde Codeplex.

Pruébenla. ¿Les gusta? ¿Es espantosa? Déjenme saber.

Intellitrace en Visual Studio 2010 y Team Foundation Server 2010

with 5 comments

Este es el séptimo (y por ahora último) artículo de la serie sobre herramientas y técnicas de testing con Visual Studio 2010, Team Foundation Server 2010, Microsoft Test Manager 2010, y C# 4.0.

Ciertos bugs pueden ser reproducidos solo si el código es ejecutado bajo ciertas condiciones. Si los desarrolladores no pueden recrear esas condiciones, es muy difícil que puedan encontrar esos bugs. Visual Studio 2010 y Team Foundation Server 2010 pueden grabar eventos y llamados durante la ejecución de los test, usando Intellitrace. Los desarrolladores pueden luego depurar el código reproduciendo los archivos grabados por Intellitrace, como si estuvieran usando un videograbador: pueden moverse hacia atrás y adelante en el call stack, analizar valores de parámetros y resultados, etc., aun cuando su entorno sea completamente diferente del entorno en el que se grabó el archivo Intellitrace.

También pueden descargar el video.

Written by fernandomachadopiriz

24/05/2010 at 16:34

Incluyendo tests en los builds con Team Foundation Server 2010

with one comment

Este es el sexto artículo de la serie sobre herramientas y técnicas de testing con Visual Studio 2010, Team Foundation Server 2010, Microsoft Test Manager 2010, y C# 4.0.

Sólo porque el código compile, no podemos asegurar que no tiene bugs. Recién cuando pasa todos los tests, podemos tener cierto grado de confianza, dependiendo de qué tan buenos sean los tests. Team Foundation Server 2010 permite agregar fácilmente la ejecución de los casos de prueba al proceso de build, generando automáticamente bugs en el repositorio de work items para los tests que fallaron.

También pueden descargar el video.

Publicaré mas videos proóximamente. ¡No se los pierdan!

Written by fernandomachadopiriz

24/05/2010 at 16:29

Test Impact Analysis en Visual Studio 2010

with one comment

Este es el quinto artículo de la serie sobre herramientas y técnicas de testing con Visual Studio 2010, Team Foundation Server 2010, Microsoft Test Manager 2010, y C# 4.0.

Cada vez que se modifica el código, es necesario ejecutar nuevamente todos los casos de prueba, para asegurar que no se introdujeron bugs en el código previamente libre de bugs; esto se denomina test de regresión. Cuando la cantidad de tests crece, el tiempo para ejecutarlos también crece. Con test impact analysis, Visual Studio selecciona el conjunto mínimo de test para cubrir código modificado, optimizando el tiempo requerido para hacer tests de regresión. En este video verán una modificación a un método Sustract de una clase Calculator, y cómo Visual Studio selecciona sólo el unit test que prueba ese método.

También pueden descargar el video.

Publicaré mas videos proóximamente. ¡No se los pierdan!

Written by fernandomachadopiriz

24/05/2010 at 16:23

Seguir

Recibe cada nueva publicación en tu buzón de correo electrónico.

Únete a otros 200 seguidores