The third drop of Prism 4.0 (formally known as the Composite Application Guidance for WPF and Silverlight) has been released and can be found in Codeplex.

We are early in the process of creating Prism 4.0 so we really need your feedback on the drop and on what you want for this version of prism.

The assets included in the drop are:
•    QuickStarts (The QuickStarts are located in the QuickStarts folder):
    ◦    Model-View-ViewModel (MVVM). Note this QuickStart requires Silverlight.
    ◦    Modularity using Managed Extensibility Framework (MEF). WPF and Silverlight versions. Note that this QuickStart requires the .NET Framework 4.0.
    ◦    Modularity using Unity. WPF and Silverlight versions. Same functionality as the MEF Modularity QS, but using Unity as the dependency injection container.
•    How to solutions: Simple MVVM: You can find beginning and ending solutions of a very simple MVVM application. This is provided to help you learn the MVVM pattern.
•    Stock Trader Reference Implementation
•    Documentation (CHM): Includes work-in-progress documentation created for Prism version 4.0.

Major Changes in this drop
•    Modularity using Managed Extensibility Framework (MEF) QuickStart.  The ModuleManager class now implements the Async pattern.
•    Modularity using Unity QuickStart. Added the Silverlight and Desktop versions of this QuickStart.
•    Added the How to solution: Simple MVVM application.
•    Added work-in-progress documentation – new topics only.
•    MVVM QuickStart: 
    ◦    Changed the Questionnaire service to be only asynchronous.
    ◦    Simplified the example, by removing the templates concept. There is a new QuestionViewModel<T> generic class. Every question type inherits from this class. The QuestionnaireViewModel creates a view model for each question using the QuestionViewModelFactory class that retrieves a new view model for each question based on its type. For more information, see the ViewModels/QuestionnaireViewModel.cs file.
    ◦    Simplified the INotifyDataErrorInfo interface implementation:  Model errors are no longer stored in an IEnumerable instance provided by the ViewModel base class, but in an instance of the new ErrorsContainer class. This class contains the implementation of the INotifyDataErrorInfo interface and stores the errors in a Dictionary, where the key is the property name and the value could be of any type that represents the validation error of that property. For more information, see the Infrastructure/ViewModels/ViewModel.cs and the Infrastructure/ErrorsContainer.cs files.

Figure 1 -MVVM QuickStart

Hope this helps,

Diego

A couple of days ago, the first drop of Prism 4 was released. Keep in mind that this has many work-in-progress stuff, but the idea is that you can see where we are heading, and also give us feedback on what you want for this version of prism.

Model-View-ViewModel QuickStart

This QuickStart demonstrates how to create a basic Silverlight application using the MVVM pattern. Note that this QuickStart is independant of the Prism Library.

The following challenges are addressed in this QuickStart.

• Implementing the INotifyPropertyChanged interface
• Hierarchical view models
• Validations
• Animations

For more information about the MVVM QuickStart, see Matias Bonaventura’s post.

What’s next 

The following changes can be expected for the next drop.

• We will ship draft documentation for the MVVM QuickStart.
• The UI styling for the QS was improved, where there will be information icons that display implementation details right on the application.
• The ViewModelBase class will be renamed to ViewModel class, and the INotifyDataErrorInfo interface will be implemented explicitly.
• Data templates will be separated from the QuestionnaireViewModel and put into different views.
• The commanding approach is changed, now we use one of the bulit-in Blend behaviors: the CallMethodAction behavior, and simulate the CanExecute method of the ICommand interface, by binding a boolean method that determines if the control is enabled or not to the IsEnabled property of the control.
• The implementation of some of the ViewModel methods will be simplified.
• Code comments will be added.

MEF/Modularity QuickStart

This QuickStart shows how to load and initialize different modules that have dependencies between them using the Prism Library and MEF.

Challenges:

• How to use MEF for modularity
• Show the different types of module loading
  1. Modules defined in a configuration file
  2. Modules defined in a directory
  3. Modules defined in a XAML file
  4. On Demand modules

What’s next

Some of the next steps for this QS are:

• The Silverlight implementation of the QuickStart will be added.
• Support for background download progress and completion for asynchronous Module calls will be added.
• There will be consistency when loading modules for both Silverlight and WPF.

Expect the next Prism drop for next week.

As always remember that we are community-driven, therefore your feedback is much appreciated and helps making the new version of Prism. You can leave your feedback in the Codeplex site.

Hope this helps,

Diego

I’m proud to announce that the Composite Application Guidance for WPF was released in Book format and it is published by Microsoft Press.

We introduced the book this week at Microsoft PDC and it was a great success. Every copy was sold out on Tuesday with lots of people wanting more.

Overview
The Composite Application Guidance for WPF is a set of guidance designed to help you manage the complexities you face when building enterprise-level Windows Presentation Foundation (WPF) client applications. This guidance helps you design and build flexible composite WPF client applications using loosely coupled, independently evolvable pieces that work together and are integrated into the overall application. This type of application is known as a composite application. This guide spans a wide range of topics from the conceptual drivers to the architecture of the Composite Application Library. The guidance is intended to appeal to a broad technical audience to help you understand proven practices for creating composite applicatiions and evaluate the Composite Application Library.

Who should read this guide:

• Application Architects
• Developers
• IT consultants
• System Integrators

What this guide covers:

• Key challenges in building composite applications and guidance on the solutions to solve these challenges.
• Software design patterns applied in the Composite Application Library
• Candidate composite architecture that you can use to create your own baseline architecture
• Stock Trader Reference Implementation, which demonstrates an implementation of the baseline architecture
• Technical implementation details of the Composite Application Library
• How to design a UI for applications using the Composite Application Library
• Pointers to the Hands-On Lab, QuickStarts, and How-to topics on MSDN

I hope that you find this useful. As always we are open to hear feedback from you.

Diego

Pueden descargar las filminas de la charla “Introducción a Scrum y casos de aplicación exitosa desde aquí: Powerpoint 2007 y PowerPoint 97-2003.

La charla fue dictada el viernes 15 de agosto en la UTN Facultad Regional Resistencia durante el marco de las 9nas JUTI (Jornadas Universitarias Tecnológicas sobre Informática).

Cualquier consulta, duda o feedback de la charla, será bienvenida.

The deck from a conference I gave on August 15th can be downloaded from here:
Powerpoint 2007 version and PowerPoint 97-2003 version.

The conference was “Introduction to SCRUM and successful implementations”

The conference was given at the UTN Facultad Regional Resistencia during the 9th JUTI (Jornadas Universitarias Tecnológicas sobre Informática).

Any doubts or feeback will be welcome.

Saludos/Cheers,
Diego

Today we published the Composite Application Library for Composite UI Application Block developers guidance at Codeplex.
You can find the PDF in the CAL Getting Started page under the  section “Interested in Migrating from the Composite Application Block (CAB)?”.

This guidance will help those CAB developers that want to migrate their applications to the Composite Application Library and those who want to give it a try.

The guidance states the main reasons to migrate to the Composite Application Library for WPF and compares both libraries. This will help you to better understand how the concepts in CAB map to CAL.

The guidance includes code comparison, figures and comments. For example, the following figure compares the equivalent elements between the WPFQuickstart solution shipped with the Composite UI Application Block in the Smart Client Software Factory and the WPFQuickstart solution rewritten to use the Composite Application Library.

It also includes an interesting appendix which shows how to emulate WorkItems in CAL, using controllers with scoped containers.

We are looking forward to have feedback from your side on this guide in order to improve it before publishing it on MSDN.

I hope it helps,

Diego

Continuing with my previous post. Now I will be describing some of the Composite Application Library (Prism) concepts in more detail.
The following sections will describe how to create an application using the library and some of its key features.

How to create a new application that uses the Composite Application Library

To create an application that uses the Composite Application Library, you just have to create a new WPF Application project.

After that create a folder where you will put the Composite Application Library assemblies and add references to them.

You will use the recently created project as a Shell project. Typically, in a composite application, the Shell project provides an UI extensibility point where the views that compose the application will be shown.

You can see the XAML markup of a basic Shell window, containing an empty control defined as the main region, in the following snippet.

Bootstrapper

In an application that uses the Composite Application Library, you use a bootstrapper class to initialize the application. Having a bootstrapper gives you more control of how the Composite Application Library components are wired up to your application.

Typically, the bootstrapper initializes the container used for dependency injection, registers infrastructure services and region adapters, creates and shows the shell window, and loads modules.

The Composite Application Library comes with a default abstract UnityBootstrapper class that handles this initialization using the Unity container. Typically, you use this base class to create a derived bootstrapper class for your application.

The Composite Application Library allows you to choose the Dependency Injection container that your application will use because it is unaware of the container. The library brings out-of-the-box support for the Unity container; however, one of the architectural principles of the Composite Application guidance is Extensibility, therefore the container, as other library pieces, can be easily replaced.

If you are using a container other than Unity, you should write your own container-specific bootstrapper.

The bootstrapper’s CreateShell method must be overridden because it is declared as an abstract method in the base class.

You can see the typical implementation of the CreateShell Method in the following snippet:

Working with Modules

A module is a logical unit in your application and represents a set of related concerns. Modules created with Composite Application Library are defined in such a way that they can be discovered and loaded by the application at run time. Modules do not reference each other but they communicate with each other in a loosely coupled way.

A module initializer class should implements the IModule interface. This interface contains a single Initialize method that is called during the module’s initialization process.

In the Initialize method of your module initializer class, you implement logic to initialize the module. For example, you can register views and services or add views to regions.

Module loading is the process of loading modules into the application and initializing them. Modules are listed by the module enumerator service. The module enumerator creates a collection of metadata about those modules that can be consumed by the module loader service. After that, the module loader service loads the modules, instantiates the module initializer classes of each module, and invokes the Initialize method on them.

Types of Module Loading

You can load modules in several ways provided by the library, but you can also provide your own custom implementation.

The following are types of module loading supported out-of-the-box by the Composite Application Library:

• Static module loading. When you statically load a module, the shell contains a reference to the module’s assembly. Static module loading provides less decoupling of the shell with modules than dynamic module loading. However, in cases where decoupling modules from the shell is not a requirement, loading modules statically can reduce code complexity, simplify the application deployment, improve startup performance, and simplify debugging compared to dynamic loading.
• Dynamic module loading. When you dynamically load a module, the shell does not contain a reference to the module’s assembly; instead, modules are dynamically discovered at run time when the application starts. By doing this, the shell is decoupled from the modules. This implies that you can add, update, or remove modules from your application without recompiling the Shell project. There are two dynamic module loading provided by the library:
  • Directory lookup: This approach allows you to configure the modules using attributes in code and does not require a configuration file.
  • Configuration: This approach allows you to specify the modules in the application configuration file and does not require you to use attributes in code.

The following table shows the bootstrapper’s GetModuleEnumerator method configured to use each type of module loading.

When modules are configured to be loaded using the ConfigurationModuleEnumerator, you have to add the corresponding section to the app.config file and configure that section.

Views and Regions

A region is a mechanism that developers can use to expose to the application’s WPF container control as components that encapsulate a particular visual way of displaying views (typically, views are user controls). Regions can be accessed in a decoupled way by their name and support adding or removing views dynamically at run time.

Because the library is designed to be extensible, it does not enforce you to use a specific view pattern. Therefore, you can use the pattern that suits your application better. See the “Separated Presentation” section in the library documentation for more information.

The following controls are supported out-of-the.box to be exposed as regions:

·         ContentControl and derived controls

·         ItemsControl and derived controls

·         Controls derived from Selector

Region Manager

The region manager service is responsible for maintaining a collection of regions and creating new regions for controls. Typically, you interact directly with this service to locate regions in a decoupled way through their name and add views to those regions. By default, the UnityBootstrapper base class registers an instance of this service in the application container. This means that you can obtain a reference to the region manager service in the application by using dependency injection.

Commands

Commands handle UI actions in a decoupled way. The Composite Application Library provides two command types.

Delegate Commands

The DelegateCommand allows you to delegate the commanding logic instead of requiring a handler in the code behind. It uses a delegate as the method of invoking a target handling method.

Additionally, because it accepts delegates, it removes the need for creating a new command type that implements ICommand for every instance where you need commanding. Also, it does not rely on control focus or the element tree as the RoutedCommand does, which can reduce headaches in composite applications, where pieces of the UI are pushed from different modules.

In the case of the Order module from the Commanding QuickStart had a Save Order command that was bound to a Button control in the UI. This is a simplified version of the code:

And from the view in XAML:

Composite Commands

The CompositeCommand is a command that has multiple child commands.

In the Commanding QuickStart, the Order module is using a CompositeCommand command to implement the Save All Orders functionality from the toolbar, where all the individual Save Order commands are called at a single button click.

Event Aggregator

The Event Aggregator service enables loosely coupled communications between components in your application. This service implements the publish/subscribe pattern, where the publishers do not send their messages to specific receivers, instead they publish to the service and subscribers receive only messages that are of their interest.

The real work of connecting publishers and subscribers is done by the CompositeWpfEvent class. This class maintains the list of subscribers and handles event dispatching to the subscribers.

The CompositeWpfEvent class is a generic class that requires the payload type to be defined as the generic type. This helps enforce, at compile time, that publishers and subscribers provide the correct methods for successful event connection.

Subscribing to an Event

Subscribers can enlist with an event using one of the CompositeWpfEvent available Subscribe method overloads. There are a number of options for subscribing to CompositeWpfEvents. The following code shows an example of event subscription.

Publishing an Event

Publishers raise an event by retrieving the event from the EventAggregator and simply calling the Publish method. As it can be seen in the following snippet.

Summary

This post is a pretty long one, but hopefully helps you realize the advantages of composite applications when developing enterprise-level applications between different teams. It is intended to provide a reasonably broad look at the Composite Application Library and all its features, and to show how easy it is to start developing applications with it.

While many of the concepts were redesigned from the Composite UI Application Block (CAB), the Patterns & Practices team has done an excellent job by incorporating customer and user’s feedback in the development of the library, thus, creating a simpler, more lightweight, less invasive and extensible library.

Therefore if you want to create a composite application taking advantage of WPF capabilities or upgrade an existing WPF application to a composite application, you definitely should take a look at the Composite Application Library.

If you want to learn more about the Composite Application Guidance, I strongly recommend giving the documentation a try, because it is very exhaustive and easy to read.

I hope you find it useful,

Diego

This tool is made to simplify the monotonous task of creating batches of code snippets. It generates each XML snippet by completing some fields, and it also generates the Visual Studio Installer (.VSI) file to integrate the package of created snippets to Visual Studio.

This tool was very useful in projects in which we developed Labs, which had tons of code snippets.

New features:

· Load/Save Project: You can save a project if you plan to change it later and load an existing project.

· Code Snippet Editor improved: The code editor was improved with syntax coloring depending on the selected language and line numbering. Thanks to Jonathan Cisneros for his valuable help on implementing this feature.

· Improved User Interface and Experience and fixed reported bugs.

· Code refactored: The code of Snippet Creator was improved a bit. I’ll plan on continuing doing this until the source code is released. Thanks to Julian Dominguez and Ezequiel Jadib for refactoring tips.

Next features

On the future I wish to implement:

· Loading a project from a .vsi file

· Help

· Installer

You can download it from here: SnippetCreator.zip

To use it just unzip all files into a folder. e.g. “C:\SnippetCreator”

If you need further help on the tool please visit the first Snippet Creator post.

Remember that your feedback is very important.

I Hope you find it useful,

Diego

I am proud to announce that we release the Composite Application Guidance for WPF both on Codeplex and on MSDN.

For the past months I have been working with the Patterns & Practices team in the development of the Composite Application Guidance for WPF. I took part of the documentation team, we worked hard to provide an excellent documentation and as a result we had really good feedback from users on the included documents.

Overview. What is the Composite Application Guidance for WPF?

The Composite Application Guidance for WPF is a set of Guidance designed to help you build enterprise-level applications composed of multiple independent and loosely-coupled pieces of software that work together to compose a single application.

Package Contents

The Guidance includes the following elements:

• The Composite Application Library and Unity binaries
• The StockTrader Reference Implementation
• 4 QuickStarts: UIComposition QS, EventAggregation QS, Modularity QS and Commanding QS
• Composite Application Guidance Hands-On Lab
• API Documentation
• Composite Application Guidance Documentation

Documentation

The following diagram shows what is included in the Composite Application Guidance Documentation:

I strongly recommend you to check the documentation because its very exhaustive and easy to read. I think it is an excellent starting point to learn the basics if you are new to composite applications and patterns usage, as well as if you are a CAB (Composite Application Block) developer.

Technorati Profile 

UPDATE: UI was improved a little.

Hi people, I decided to release this tool I’ve made to help during a project’s development.

This tool is made to simplify the task of creating batches of code snippets. It generates each XML snippet by completing some fields, and it can also generate the Visual Studio Installer (.VSI) file to integrate the package of created snippets to Visual Studio.

This tool was very useful in projects in which we developed Labs, which had tons of code snippets to simplify user’s lives. The tool makes this monotonous task a little simpler.

The application’s features are:

• Create a project: This creates a folder which will contains all generated code snippets.
• Create code snippets: Once you complete all the required fields it generates a .snippet file or updates it, if it is an already generated snippet.
• Generate VSI: Once you create all the snippets, this option generates an installer package that will automatically install the snippets into Visual Studio.
• Auto-complete: If this feature is enabled, the filename and shortcut of the snippet is auto-generated from the title. The name convention used is the one we use when developing labs.
• When you select a snippet in the list, you can edit it by double-clicking on it, or delete it by pressing the DEL key.

I intend to update this application to help people developing applications such as Labs or anyone who would like to use it. Feedback is welcome and also bug reporting.

The next features I will try to implement are:

• "Project management": Load, Save, Delete & Close Projects
• Help
• Improve the UI: It’s pretty basic now.
• Installer

Screenshots

Creating a Snippet

Creating a VSI with multiple snippets

Testing the Visual Studio installer

You can download it from here: SnippetCreator.zip (temp hosting till I find a better place :P)
To use it just unzip the two files into a folder. e.g. "C:\SnippetCreator"

I Hope you like it;
Diego

He decidido publicar este post que lo habia redactado hace un tiempo. Pretende ser una pequeña introduccion a la metodología de desarrollo ágil SCRUM. Pero como todos saben para aprender una metodología hay que leer mucho y sobre todo practicarla hasta dominarla. Espero este sea un buen punto de partida para aquellos interesados en comenzar a utilizarla. El texto es un resumen de lo expuesto por Ken Schwaber en su libro “Agile Project Management with Scrum“.
Espero este sea el primero de varios posts relacionados con Scrum.

Scrum

Un control de proceso empírico, se basa en tres principios: transparencia, inspección y adaptación.

La transparencia se refiere a que aquellos aspectos del proceso que afectan al resultado, deben ser visibles y conocidos por aquellos que controlan el proceso.

La inspección requiere que los aspectos del proceso sean inspeccionados con la frecuencia necesaria, para que las desviaciones inaceptables del proceso puedan ser detectadas.

Adaptación, si uno o más aspectos del proceso están fuera de los límites aceptables, el inspector debe ajustar el proceso o el material procesado. Esto debe hacerse lo más rápido posible para minimizar una mayor desviación.

Scrum es un control de proceso empírico, implementa los tres principios mediante un conjunto de reglas y prácticas simples.

Scrum emplea como esqueleto un proceso iterativo e incremental del cual derivan todas sus prácticas.

Opera de la siguiente manera: Al comienzo de cada iteración, el equipo revisa que debe hacer. Luego selecciona lo que cree puede transformar en un incremento de funcionalidad entregable al final de una iteración. Después se deja al equipo que haga su mejor esfuerzo por el resto de la iteración. Al final de la iteración, el equipo presenta el incremento de funcionalidad que construyó, para que los Stakeholders puedan inspeccionarlo y hagan adaptaciones al proyecto.

El corazón de Scrum ocurre dentro de la iteración. El equipo mira los requerimientos y la tecnología, y evalúa las habilidades y capacidades de cada integrante. Luego idea colectivamente la mejor manera que conoce de construir la funcionalidad, modificando el enfoque diariamente, a medida que encuentra nuevas complejidades, dificultades y sorpresas. El equipo decide que necesita hacerse y la mejor manera de hacerlo.

Roles:

Existen 3 roles: Product Owner, El equipo y el ScrumMaster.

El PO es responsable de representar los intereses de cualquier involucrado en el proyecto y el producto resultante. Crea inicialmente los requerimientos generales del proyecto, objetivos de retorno de inversión, y planes de lanzamiento.

La lista de requerimientos se llama Product Backlog.

El PO es responsable de usar el Product Backlog para asegurarse de que la funcionalidad más valiosa sea producida primero, esto se logra priorizando frecuentemente el Product Backlog para encolar los requerimientos más valiosos para la siguiente iteración. Es también responsable del éxito del producto.

El equipo es responsable de desarrollar la funcionalidad. Los equipos son auto-administrados, auto-organizados e interfuncionales. Un equipo es responsable de descubrir como convertir el Product Backlog en un incremento de funcionalidad dentro de una iteración, y administrar su propio trabajo para lograrlo.

El ScrumMaster es responsable del proceso Scrum, de enseñarlo a todos los involucrados en el proyecto y asegurarse de que todos sigan sus reglas y prácticas.

Flujo

Todo el trabajo se hace en los Sprints. Cada Sprint es una iteración de un mes, y es iniciada con una Sprint Planning meeting (Reunion de Planeamiento del Sprint) donde el PO y el equipo colaboran sobre que se va a hacer en el siguiente Sprint.

El equipo selecciona del Product Backlog todo lo que cree que pueda convertir en un incremento de funcionalidad entregable para el final del Sprint. Cada incremento debe consistir de código escrito, exhaustivamente testeado y bien estructurado que ha sido compilado en un ejecutable. La operación de usuario de la funcionalidad, debe ser documentada.

Al final del Sprint, se realiza la Sprint Review Meeting, es una reunión de 4 horas reloj en la cual el equipo presenta lo que fue desarrollado durante el Sprint al PO y cualquier otro stakeholder que desee asistir.

Luego de del Sprint Review y antes de la siguiente Sprint Planning meeting, el ScrumMaster mantiene una reunión de Retrospectiva del Sprint con el equipo. En esta reunión de 3 horas reloj, el ScrumMaster, alienta al equipo a revisar, dentro del marco de trabajo y prácticas del proceso Scrum, el proceso de desarrollo para hacerlo más efectivo y disfrutable para el siguiente Sprint.

Este conjunto de reuniones implementan las prácticas de inspección y adaptación, dentro del Scrum.

Artefactos

Product BackLog

Los requerimientos para el producto siendo desarrollado están listados en el Product Backlog. El PO es responsable del Product Backlog, su contenido, disponibilidad y su priorización. El product Backlog evoluciona con el producto.

Burndown Chart

Muestra la cantidad de trabajo que falta en relación con el tiempo. Es una manera de visualizar la correlación entre la cantidad de trabajo faltante y el progreso de el/los equipo/s de proyecto en reducir este trabajo. Es la relación entre la realidad (trabajo hecho y que tan rápido está siendo hecho) con lo que está planificado.

Sprint BackLog

Define un subconjunto de trabajos o tareas, que un Equipo selecciona del Product Backlog, para realizarlas en un Sprint, y convertirlas en un incremento de funcionalidad entregable del producto.
Las tareas deberían tener el suficiente detalle para que tome aproximadamente entre 4 y 6 horas el terminarlas. Solo el equipo puede cambiar el Sprint Backlog.