Prism 4 - Navigating to scoped regions, not quite.

I think many of us have been let down by the new version of PRISM...

The first thing that stands out in the new version is the Navigation API. When I first read it, it sounded brilliant. The idea and concept makes navigation in MVVM seems a breeze (previously resorting to IEventAggregator) so I was too quick to download the new build and tried it out. I also read Karl Shifflett's blog through and through and was ready to begin my first application using the new Navigation API.

The first thing you will notice is that its "relatively" simple to follow through and understand. I quickly got a working simple application using the new API. Notice how I used the word simple. This is exactly how it works with these frameworks. They are wonderful when you keep things simple, but when you start to get yourself in a pool of confidence and apply it to a new/existing projects, you get hit over the head with a sledge hammer.

The first issue I came across was nested regions. Previously, I never paid any heed to scoped regions, and each module was happy to set up its own region everything was fine. Now if you use the Navigation API, you will immediately notice that you application gets spoiled by the RegionCreationException.

What has happened is not clear until you scour the internet and find a few obscure blogs about nested regions and realized that the Navigation API is not quite there yet. There are a few missing pieces to make this whole thing play nice and some have resorted to forking the Prism project to cater for this error. My question is... 

"Why have you guys not seen this?!?"

This is again my point about these frameworks (*cough* practices *cough*) that comes up with something that would seemingly make your programming life heaven, and then hammer you down with issues such as the one I have mentioned. These guys love to keep things simple... but thats what they will ever be. Simple. Never quite ready for the real world.

Module Security

If you've decided to dynamically load your WPF modules in a "plug-in" style application then you may have wondered how safe is it or how easy is it for someone to DLL inject your modules.

If you have not wondered this, then you should. Module deployment that relies on module discovery by your bootstrapper requires that you need to take into consideration of digitally signing your modules so that you know someone else is not messing around with your application.

Digitally signing your DLL can be a bit of a pain if you have not planned for it early in your development process. Strong Name Signing is the simplest way to verify your DLL but beware that strong named libraries cannot reference weak named libraries, but vice versa is possible. So plan your dependency well, keep to the PRISM pattern of de-coupling your modules via interfaces and common infrastructure libraries and you will be fine.

Commands and Command Parameters

Have you ever tried to use DelegateCommand<T> with enums being your payload?

The quick answer is that you can't. DelegateCommand<T> requires that T being a struct or class type (that is everything except enum!). So how do you get around this (god knows we hate "work-arounds").

I found that the best way to use enum-like functionality is to convert the enum into a class of constant strings. A very good example is a menu with enum type locations (eg. "Home", "Settings", "Update", etc.). By converting this enum into a class, we have:


public class LocationNames
{
    public const string Home = "Home";
    public const string Update = "Update";
    public const string Setting = "Setting";
}

So now our enum DelegateCommand<T> can be DelegateCommand<string> instead.

DataTemplate Vs. View Injection

PRISM tells us that each view needs a contracted interface, eg. IMyView which your view needs to implement.

This approach is to let us inject the views into the appropriate region (this injection usually happens in the controller). Given this guideline, what has happened to the classic MVVM approach of using DataTemplate?

Traditionally, we would have some ItemsControl to present the View-Models and define the custom DataTemplate that will define the associated view. For some, you may have noticed that when the DataContext of this ItemsControl changes, a new view is created for the new View-Model (this is sometimes an undesirable side effect).

The View Injection approach to my knowledge was derived from the Model-View-Presenter (MVP) pattern, this means that for those that has gone from MVVM to PRISM will want to keep the traditional DataTemplate to concrete view types. This is fine but as long as you are consistent in your approach.

Personally, I find that there is no need for an interface for each view because realistically you are not going to unit test the views and produce meaningful Asserts or replace any of the views through IoC any time soon.