El evento online Windows Day: “Tecnologí­a para derribar paredes” acaba de empezar!

Windows Day

Para los que no saben de qué se trata este evento, una breve descripción tomada del blog del evento:

Descubre novedades acerca de las tecnologías de implementación, administración y de desarrollo de aplicaciones en desktops con Windows Vista y con Windows 7: cómo mejorar el rendimiento, cuándo virtualizar, cómo optimizar los escritorios, incrementar la seguridad, resolver el acceso a datos y cómo crear las mejores interfaces de usuario. Conoce todas las novedades que llegan con el SP2 de Windows Vista y lo que se viene con Windows 7 y ASP.NET 4.0. Conferencias online, demos y chat en vivo con expertos para dominar las últimas tecnologí­as en desarrollo de aplicaciones Windows (y web también).


Junto al gran Miguel Ángel Saez, estaremos presentando la siguiente sesión:

Sesión MSDN-1: Dando el salto hacia el presente con Windows Presentation Foundation

Conceptos necesarios para la creación de aplicaciones de negocio, que distinguen a WPF de otras tecnologías: Estilos, DataBinding, el patrón Presentation Model y los controles DataGrid y Ribbon.

Vamos a estar introduciendo Windows Presentation Foundation (WPF), haciendo hincapié sobre el lado técnico y de arquitectura de WPF, especialmente dirigido a desarrolladores que vienen de tecnologías clásicas como WinForms, y están tanteando la madurez de WPF como plataforma de aplicaciones de negocio.

También, como pueden ver de la descripción, y como no podía ser de otra manera, vamos a estar introduciendo el patrón Presentation Model, también conocido como Model-View-ViewModel (o M-V-VM), del cual ya he escrito varios posts en inglés.

Para la demostración del uso de este patrón, estaremos utilizando una versión simplificada de la aplicación de referencia de Prism (proyecto que les recomiendo mirar si piensan crear aplicaciones de negocio complejas): Stock Trader RI.

Prism 2.0 Stock Trader Reference Implementation


Las conferencias y demos son pre-grabadas, por lo que podrás verlas en el orden y en el momento que desees, y habrá más de 50 importantes expertos de todo Latinoamérica chateando contigo en las sesiones en vivo; y en exclusiva, una sesión en vivo con Mark Russinovich.

Accede al evento aquí­: http://www.microsoft.com/latam/windowsday/

Cualquier consulta, no duden en consultarme por medio de este blog. Espero que les resulte interesante y les haga dar el salto a WPF!

A week ago we announced the Composite Application Guidance for WPF and Silverlight – February 2009 release.

A few days after, Microsoft released a new version of Silverlight (version 2.0.40115.00 or just GDR1), and it broke a build script that we were using for some of the unit tests in the CAL. This didn’t prevent the users from using the CAL, but was causing build failures with cryptical error messages. You can read the full details here.

We also got feedback from users (i.e here, here and from Brian Noyes), that when migrating an existing Prism 1.0 app to Prism 2.0 (WPF), they were experimenting inconsistencies with the activation and deactivation of views when using a TabControl as a region. You can read the full details here.

We decided to fix both issues and refresh the download bits, so you can now download them from MSDN.


What files were updated in the source code?

If you are including the CAL in you application’s source control, you might want to know exactly what files were updated.

The following are the only files updated with this refresh:

  • CAL/Silverlight/Composite.Tests/Mocks/Modules/createXap.bat
  • CAL/Silverlight/Composite.Tests/Modularity/XapModuleTypeLoaderFixture.cs
  • CAL/Desktop/Composite.Presentation/Regions/Behaviors/SelectorItemsSourceSyncBehavior.cs
  • Desktop/Composite.Presentation.Tests/Regions/Behaviors/SelectorItemsSourceSyncRegionBehaviorFixture.cs


Do you have the latest version already?

If you are not sure whether you already have the latest version of the self-extractable EXE for the source code (because the version number was not updated) you can check the timestamp of the Digital Signature. The refreshed bits should read ‘Tuesday, February 24, 2009′ (don’t mind the time, as it varies with the time zone of the PC).



More info on the refresh on Blaine Wastell’s blog and Bob Brumfield’s blog.

Happy composite application building!

Great news guys: the Composite Application Guidance for WPF and Silverlight – February 2009 has been finally released.

You’ll be glad to know that the final version of this new release is out. If you’ve been playing with the bi-weekly drops, or holding off to be able to use this already embraced guidance from WPF, but in your Silverlight projects, you can now start grinning.

Intended Audience

This guidance is intended for software architects and software developers building enterprise Windows Presentation Foundation (WPF) or Silverlight applications. Such applications typically feature multiple screens, rich, flexible user interaction and data visualization, and role-determined behavior. Additionally, these applications typically use layered architectures that may be physically deployed across tiers, strong separation of concerns, and loosely coupled components. They are “built to last” and “built for change.” This means that the application’s expected lifetime is measured in years and that it will evolve in response to new, unforeseen requirements. Applications that do not demand these features and characteristics may not benefit from the Composite Application Library.

The Composite Application Guidance is not difficult to learn, but developers must be ready and willing to embrace patterns and practices that may be new to them.


Composite Application Guidance Assets

  • Composite Application Library source code. Developers can use the Composite Application Library to develop multi-targeted applications in WPF and Silverlight that are composed of independent and collaborating modules.
  • Unity Extensions for Composite Application Library source code. This provides components to use the Unity Application Block with the Composite Application Library.
  • Stock Trader Reference Implementation (Stock Trader RI). This is a composite application that is based on a real-world scenario. This intentionally incomplete application illustrates the composite application baseline architecture. This is a good reference to see how many of the challenges when building composite applications are addressed by this guidance.
  • QuickStarts. This includes the source code for several small, focused applications that illustrate a specific challenge.
  • Documentation. This includes the architectural overview, Stock Trader RI overview, design and technical concepts for composite applications, applied patterns, How-to topics, QuickStarts overviews, and deployment topics. Much of this guidance is applicable even if you are not using the Composite Application Library, but you just want to know best practices for creating composite applications.


What’s new from Prism 1.0

  • Silverlight Support. The complete Composite Application Library, RI, QuickStarts, documentation (everything!) has been brought into life in Silverlight. The source code is targeting both WPF and Silverlight, by using linked source code files (there is of course guidance on how to develop applications that reuse code for these 2 platforms if you are planning to target both of these with the same code).
  • WPF developers won’t see much difference in the Composite Application Library itself, but there are some reasons to update:
    • View Discovery UI Composition. Modules can register views (or presentation models) against a named region. When that region is displayed at run time, any views that have been registered for that location will be automatically created and displayed within it. The Prism 1.0 way of adding views to a region is now officially called View Injection, because it does not work as a configuration mechanism, but as a explicit demand to add the view into a specific region instance.
    • RegionContext is useful when you want to share context between a parent view and child views that are hosted in a region. Think of this like flowing DataContext down, but through regions.
    • ICommand attached behavior base. Base class to help create behaviors for control events that will fire an ICommand.  This was mostly done to support executing commands in Silverlight when clicking a button, but could be applied equally well to WPF for other kind of events (such as pressing the Enter Key on a search box as it’s being demonstrated in the RI). The basic idea around behaviors for ICommand is similar to what I blogged about in this post a while ago.
    • Region extensibility. Regions are easier to extend with their functionality moving into attached region behaviors.
    • Module Catalog. This concept is easier to understand and use than the Module Enumerator and Module Loader present in 1.0. Nevertheless, migrating to the catalog from enumerators is pretty straightforward and it’s explained in the docs.
  • Project Linker. Basic tooling that helps you keep 2 projects synchronized by creating Visual Studio file links from one project to another. This is useful for sharing source code that targets both WPF and Silverlight platforms (as there is no binary compatibility).

What is different between the Silverlight and the WPF version of the Composite Application Library in this release?

    The codebase is mostly the same, except for some minor differences. The biggest of these is that Directory Lookup of modules and Configuration based module catalog is available in WPF only, whilst Silverlight supports retrieving modules asynchronously in separate XAP files, to reduce the main application size (and startup time).



A new drop of Composite Application Guidance for WPF and Silverlight (or Prism) is out. Get it from Codeplex.

The latest changes since drop 6 include:

  • Modularity

Many changes where made to Modularity to keep it simpler (although not extremely noticeable for the surface API consumer).

We also re-included the Directory Lookup and Configuration based module enumerators for WPF (the ones that were included in Prism V1), and the respective QuickStarts that show their usages.


  • Commanding

We included the Commands namespace in Silverlight’s CAL.

In order to hook up an ICommand to a button from XAML, we are following a similar approach to what we’ve done in a previous spike and blogged about it here, so I won’t go into many details about it in this post.

The CommandParameter cannot be set from XAML currently; that feature did not make it in drop 7 for a few minutes, but this will definitely be possible in the next drop.

We also ported the Commanding QS to Silverlight, although this is still work in progress.


  • Regions

There is a breaking change in the Regions property of the IRegionManager, which may not be noticeable for the majority of users, but it can break some of your RegionManager mocks if you are doing TDD (and if you are not… WHY NOT?!?!? ;-) )

  • Documentation

Changes in the documentation includes explanation of the new Pull-based Composition QuickStart and the Modularity QuickStarts for WPF.

  • Project Linker

If you like ProjectLinker or you would like to try it, but didn’t feel like installing Visual Studio 2008 SDK, you will be happy to know that it does not require the SDK anymore :)

There is a separate download for the ProjectLinker installer and for its source code, as the latter still requires the SDK if you want to update it and build it yourself.

I hope you like it, and as usual, we are driven by the community, so your feedback is very useful to us.

The 6th drop for this project is already out of the team room and into Codeplex, as it has been every 2 weeks since 2*(6-1)=10 weeks back from today.

You can see the complete list of latest changes in Erwin’s post.


The biggest changes for this drop, although not very noticeable from the outside if you’re just using the default way that Regions work without the need to extend them, are:

  • Added RegionContext

This is to provide a way to pass some context to the Views that are placed inside a particular instance of a region. You were usually able to workaround the need for this context by using EventAggregator or scoped DI containers, but luckily this will be easier to achieve for those same scenarios and for more complex ones (for example when using scoped region managers and having several instances of the same region).

  • Formalized infrastructure for extending the behavior of Regions

In Prism 1.0 there were already some ad-hoc behavior classes for extending the functionality of the regions (for example the CollectionActiveAwareBehavior or SelectorRegionSyncBehavior).

In Prism V2, we also had to rethink how the RegionManager attached properties would work in the Silverlight world, as it is different from WPF (Silverlight lacks property value inheritance). We also added features like the new Pull-based composition scenario, or the RegionContext attached property.

We started adding separate behavioral objects for these new features, which were very flexible, but very hard to understand, debug, and to know which objects were currently modifying the behavior of a particular region instance.

This created the need for an infrastructure for all of these formerly independent behavior objects, that would make the library easier to understand, extend and maintain.

The IRegion interface now has a collection of IRegionBehavior objects, so you can always know which objects are extending the functionality of a particular Region instance, and it can also couple the lifetime for these behaviors and regions, in order to prevent memory leaks when developing new behaviors.

    RegionBehaviors infrastructure in Prism V2Picture taken from Erwin’s blog post. Read the full post here

I finally got some slack time to put a small sample of Presentation Models with DataTemplates on WPF together. As I mentioned in a previous post, the combination between Presentation Model and DataTemplates can become a differentiated quality feature in your source code.
Let’s explore the sample (download link on the bottom).


The application is based on the Commanding QuickStart we shipped in the first release of the Composite Application Guidance for WPF (a.k.a. Prism or CompositeWPF). The original QS was written using presentation models, but without using automatic DataTemplates, so I updated it to create this sample.

I did not change the basic structure of the solution or the code so much, so you can compare it with the one shipped with Prism. The post assumes familiarity with the Composite Application Library (CAL) included in CompositeWPF, so I won’t get into much detail on things like the Bootstrapper, Regions, Modules, IoC Containers or Commands.


Notice how the solution does not contain any UserControl for the views. The only Window here is Shell (in the Commanding project), but it is basically empty, except for some properties like size or background.

So if the Shell window is empty. How does the application expose the main regions for the modules to start adding views? Well, in the Commanding Bootstrapper of course.

1 class CommandingBootstrapper : UnityBootstrapper

2 {

3   protected override DependencyObject CreateShell()

4   {

5      Shell shell = Container.Resolve<Shell>();

6      shell.Content = Container.Resolve<ShellPresentationModel>();

7      shell.Show();

8      return shell;

9   }

10  //…

11 }

So there in line 6 we inject the ShellPresentationModel into the Shell window, and we have our first DataTemplate view injected automatically in the Visual Tree (remember that the presentation model is not a control, and is lookless). The view template is declared in ShellResourceDictionary.xaml and included in App.xaml.

1 <ResourceDictionary xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"

2 xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"

3 xmlns:local="clr-namespace:Commanding">

4   <DataTemplate DataType="{x:Type local:ShellPresentationModel}">

5    <Grid>

6    <Grid.RowDefinitions> … </Grid.RowDefinitions>

11     <ItemsControl ItemsSource="{Binding GlobalCommandsRegion.Views}" />

13     <ItemsControl ItemsSource="{Binding MainRegion.Views}" />

18   </Grid>

19  </DataTemplate>

20 </ResourceDictionary>

I stripped most of the styling parts. Notice that there is no RegionManager.RegionName attached property here. Instead there is a binding in ItemsSource to some MainRegion.Views property path in the ShellPresentationModel (the DataContext of the template is the instance of the DataType).

If we look into this ViewModel, you can see the regions being registered in the Region Manager and exposed to the View.

1 public class ShellPresentationModel

2 {

3   public ShellPresentationModel(IRegionManager regionManager)

4   {

5     MainRegion = new Region();

6     GlobalCommandsRegion = new Region();

7     regionManager.Regions.Add("MainRegion", MainRegion);

8     regionManager.Regions.Add("GlobalCommandsRegion", GlobalCommandsRegion);

9    }


11  public IRegion MainRegion { get; private set; }

12  public IRegion GlobalCommandsRegion { get; private set; }


This keeps the composition at the Presentation Model level, instead of the UI being responsible of registering the regions.

One drawback of this particular implementation is that if I have a more complex Control that not only binds, but interacts with a region, there is no out-of-the-box behavior that will use Region Adapters to enhance this binding (in the example the ItemsControl just binds to the Views collection exposed by the region and that’s it).

But don’t discard this approach prematurely; if you need such a behavior, it could be easily solved by creating an attached behavior other than RegionManager.RegionName (BTW, this attached property IS an attached behavior…) that takes an existing region in the model and hooks it up with the target Control appropriately.

Now that the shell piece is ready to be used by CAL modules, let’s look at the OrderModule class.

1 public class OrderModule : IModule

2 {


12  public void Initialize()

13  {

14    RegisterResources();


16    IRegion mainRegion = regionManager.Regions["MainRegion"];

17    mainRegion.Add(container.Resolve<OrdersEditorPresentationModel>());


19    IRegion globalCommandsRegion = regionManager.Regions["GlobalCommandsRegion"];

20    globalCommandsRegion.Add(container.Resolve<OrdersToolbarPresentationModel>());

21   }


23   private static void RegisterResources()

24   {

25     ResourceDictionary dictionary = new ResourceDictionary();

26     dictionary.Source = new Uri("pack://application:,,,/Commanding.Modules.Order;Component/OrdersResourceDictionary.xaml");

27     Application.Current.Resources.MergedDictionaries.Add(dictionary);

28   }

29 }

As you can see, the first thing the Initialize method does is register the resources, by merging the Application’s resources with the OrdersResourceDictionary.xaml file. This allows having the resource dictionary files in the modules they belong. If you want to include the resources in the App.xaml file, you need to place the referenced files in the main project, making the idea of modularity senseless. More on this in my previous post.

Then the Initialize method adds the presentation models (as opposed to the Views in the original QuickStart) to the regions in order for WPF to "show" them, by automatically injecting the correct template defined in the resource dictionary.

If you dig into the OrdersResourceDictionary.xaml file, you’ll find some DataTemplates for the presentation models, and also some styles, converters and templates used to show validation errors in the the view. These are there to show that not only trivial views can benefit of this pattern, but also views that has some UI logic that is not a simple binding of a textbox.

And if converters are not enough for your templates, don’t hesitate on adding attached behaviors to cover the lack of code-behind gap, and still keep testability and reusability to the maximum.

My opinion on converters: just because they exist and can be very helpful, try to keep these in low numbers, and, instead, expose properties in the presentation models that can be easily bound to. Even if you can test these converters separately from the views, they can start to make your code less intuitive. Nevertheless, try to keep a balance and create a presentation model that is at the same time agnostic of the view that will represent it, but easily bound from a view (which is the purpose of a presentation model).

As you develop the views, you’ll notice the importance of commands to execute logic in the presentation models, as you cannot handle the Click event in the code-behind. In this example we’re not using the RoutedCommands that come with WPF, but another implementation (DelegateCommand) that is included in CompositeWPF. You can also use attached behaviors that end up invoking commands or actions on the presentation model in response to other control events.

Download the code to get into the implementation details for the views.


This code is provided "AS IS" with no warranties. You can use it freely. It includes the binaries of Composite Application Library and Unity Application Block.


Download the Presentation Model with Prism Sample (for Visual Studio 2008).

kick it on DotNetKicks.com

If you want to know what has been keeping us busy for Prism vNext, read this detailed post from David Hill.

An excerpt from his post:

Prism 2.0 will focus on two things:

  • Extending the guidance delivered in Prism 1.0 for building composite WPF applications to also support composite Silverlight applications.
  • Adding guidance for building ‘multi-headed’ applications – applications that can deliver both a desktop and an in-browser experience.

David Hill has been working and contributing with p&p in many projects, and has recently become the new architect at p&p. So be sure to add David to your RSS, because there’s probably lots more to come related to the guidance that p&p is providing not only with Prism vNext, but with other assets like EntLib.

The Composite Application Guidance for WPF (formerly known as Prism) was finally released as Release Candidate in the codeplex site. The final release will be published on MSDN soon.

If you haven’t been following the weekly drops, here’s a quick summary of the contents, as this guidance comes in many forms, such as:

  • Composite Application Library

      This class library comes in form of source code. You can build it, reference it, extend it, modify it, extract pieces of it, or do whatever you feel like with it because it’s under Ms-PL (all the source code in the release, including CAL, the Reference Implementation and QuickStarts, are under this license).

    The Composite Application Library is designed to address requests from architects and developers who create WPF client applications and need to accomplish the following:

    • Build clients composed of independent, yet cooperating, modules.
    • Separate the concerns of module builders from the concerns of the shell developer; by doing this, business units can concentrate on developing domain-specific modules instead of the WPF architecture.
    • Use an architectural framework to produce a consistent and high quality integrated application.
  • Documentation

      Totally wicked documentation! It’s useful for both architects and developers. This is not the typical last minute documentation after a project ends, but an awesome first class citizen of the project… you should definitely check it out.
      Composite Application Guidance for WPF documentation
  • Reference Implementation

    [The RI] is an application that illustrates the baseline architecture. Within the application, you will see solutions for common, and recurrent, challenges that developers face when creating composite WPF applications.

    The reference implementation is not a real-world application; however, it is based on real-world challenges customers are facing. When you look at this application, do not look at it as a reference point for building a stock trader application… instead, look at is as a reference for building a composite application.

    Stock Trader Reference Implementation

  • QuickStart sample applications

    The QuickStarts […] are brief, easy-to-understand illustrations of key software factory activities. QuickStarts are an ideal starting point if you want to gain an understanding of a key concept and you are comfortable learning new techniques by examining source code. The Composite Application Guidance includes the following QuickStarts:

    • Dynamic Modularity
    • UI Composition
    • Commanding
    • Event Aggregation

I guess all that is left is for you to download it and try it out, as it is very easy to consume and find out if it’s good for you or your team.

Remember there is also a community and active forums to help you building you composite applications with the library. So if you have any issues, doubts, comments, feedback, please stop by the codeplex discussion list for the project.

Happy coding!

Download Composite Application Guidance for WPF

UPDATE: Link to final release landing page on MSDN

Technorati Profile

In my previous post I talked a little of a new way that WPF allows us to create (and inject) a view by using DataTemplates (or ControlTemplates). I talked about how the use of templates combined with the Presentation Model pattern can help you build fully testable applications.

I was contrasting the benefits of using Presentation Model against the Passive View’s flavor of the MVP pattern when using it in the WPF world. I want to clarify that the Stock Trader reference implementation that’s being shown with the Prism project is not using Passive View (it was in the very first drop, but not anymore)… it has a mix of MVP with Supervising Controller (as of today).

The spike made by the Prism team that I was talking about was released here (get the zip, and the spike is under the PublishedSpikes folder).

The spike was based on the existing UIComposition QuickStart, so not all the code there is related to DataTemplates (as I said, it is just a spike and not production code, but we thought it would be interesting to put it out there). You are very welcomed to check it out. I won’t use the same example as the spike in this post, as I want to focus only on the templating part and leave the rest out.

One very neat thing about using templates, is whenever you add a model into the Visual Tree, WPF will automatically inject the view (template), assign the model as it’s DataContext and render it on screen. How? Well, let’s see an example.

You first need to create the DataTemplate you want to use:

<DataTemplate DataType=”{x:Type models:OrderModel}”>

      <Label Grid.Row=”0″ Grid.Column=”0″>Customer Name</Label>
<TextBox Grid.Row=”0″ Grid.Column=”1″ Text=”{Binding CustomerName}” />
<TabControl ItemsSource=”{Binding LineModels}” />
<Button Command=”{Binding SubmitOrder}”>Submit</Button>

You could place this portion of XAML in the App.xaml as a resource, but if you do this for every view in one centralized place, that file can get very big, hard to read, hard to manage, and what is worst, all devs or designers will try to edit that file constantly at the same time. Furthermore, if you’re developing different modules (like what you could do with Prism), you will not be able to deploy the modules independently.

Best option: create separate ResourceDictionary files where you can put one or a few tamplates grouped logically. Later on, you can merge these resource dictionaries by using MergedDictionaries in the App.xaml as explained here.

“Ok now, but if I’m using Prism, I cannot accomplish decoupled modules if now my application class has to know about all the resource files in all my modules!”. Fortunately, all that can be done in XAML can be done programatically, so instead of using MergedDictionaries on App.xaml, you could have your Module initialization logic to merge the isolated dictionaries into the application wide ResourceDictionary. In the spike published by the Prism team, this is done with the following code:

ResourceDictionary dictionary = new ResourceDictionary();
dictionary.Source = new Uri(“pack://application:,,,/OrdersModule;Component/OrdersRD.xaml”);

Now that the initialization has being done, all you need to do is “show” this model. For example:

Window mainWindow = new Window();
mainWindow.Content = new OrderModel();

On the next posts I’ll try to gather a downloadable sample, and show how to use commands to work in these scenarios. Also I’ll show how to use two-way bindings to communicate actions from the view to the model when commands are not enough.

kick it on DotNetKicks.com

In this post (of what may become a series of posts if I find some interest from the community) I compare 2 different approaches for separating view code from business logic in order to reduce the untested surface area while doing TDD.

The Passive View pattern

I have been using the Model View Presenter (MVP) pattern (or more specifically the Passive View pattern) for a long time now, both in the Winforms and WebForms worlds.

The main reasons for this? Testability and separation of concerns. As a TDD adopter, I want to be able to unit test as much logic as I can.

Passive View works fairly well, allowing me to keep the view (usually in the form of a user control) somewhat thin in order to satisfy myself without testing it (you know how difficult/impossible it becomes to unit test a UI screen).

In practice, applications written using Passive View end up having lots of boiler plate code for the communication between the view and the presenter. It also makes it very prone to start putting more knowledge on the view than what I’d like, not only for laziness in trying to avoid forwarding messages (that require very simple processing) to the presenter, but also in some transformations needed to keep the presenter agnostic of the specifics of the UI implementation.

WPF templates to the rescue!

In the Prism project we’ve using the Passive View approach also, as a logical step to adopt WPF when you come from winforms / webforms.

In the last time, though, I have been becoming very fond of another approach that is very easy to implement now using the WPF templating and databinding capabilities that weren’t available before: the Presentation Model pattern. This has been also called Model-View-ViewModel by John Gossman / Dan Crevier (if you haven’t read their blog posts on this topic, you MUST read them).

What I would like to add/highlight in this approach is that in WPF you can enforce keeping your view extremely thin by avoiding the use of UserControls or UI-coupled controls. Instead, you can create DataTemplates of your Presentation Model classes, and those model instances are the objects you’ll add to your Window. When your model gets laid out in the visual tree, WPF will automatically pick up the correct template for that model, and render the model appropriately.

This approach relies extremely on data binding, because there is no code behind at all on the views, just XAML markup.

Most of the times I end up deriving my presentation models from DependencyObject to benefit a lot from dependency properties.

In some cases where UI complexity dictates it, the model may derive from Control instead. "What?!? a model deriving from a Control?". That was my first thought when I came to that possibility, but it was highly biased from my Winforms past. Controls (don’t mistake with UserControls) in WPF are totally lookless and do not rely on the UI, so they can be tested in isolation. To render the appropriate view you’ll need to create a default ControlTemplate (compared to a DataTemplate for plain objects or DependencyObjects). One big benefit about using Controls is that you can maintain a WPF logical tree of presentation models (there are some benefits about this which I won’t cover in this post).

I’m planning on providing you with some code samples in the future, but in the meantime guess what: The latest Prism code drop will be including a spike we did using this approach. You should check it out and see how it feels. Notice that this is just a spike and we are only releasing it in order to get feedback from you guys, and see what is the interest on seeing more of it.