Why not let XAML code-behind implement IModule?

Topics: Prism v2 - Silverlight 4
Oct 20, 2010 at 8:34 AM
Edited Oct 20, 2010 at 9:29 AM

Hi to all,

I've been experimenting with Prism 2.2 for SL4 according to this example by Jeremy Likness:

http://www.wintellect.com/CS/blogs/jlikness/archive/2010/03/15/10320.aspx

I noticed that in this example - and many others for that matter - that for each composite View there's an associated Module created as a separate class. Assuming we're implementing MVVM, that means each 'View' has the following files associated with it:

  1. the XAML (Orders.xaml)
  2. the XAML code-behind (Orders.xaml.cs)
  3. the ViewModel (OrdersViewModel.cs)
  4. the PRISM Module that implements IModule (OrdersModule.cs)

I'm aware that the Module class doesn't have to be an actual file and be written / included somewhere else, but for complexity's sake and to adhere to what the various PRISM examples are showing, let's assume that the Module is in a separate file.

I dunno, but that seems a lot of files for 1 View. Sure it's a small price to pay for the composition, decoupling and good segregation that PRISM and MVVM offer but here's where this thread's title comes into play: Why not let XAML code-behind implement IModule?

Theoretically it's feasible - it's just an interface implementation - but it doesn't show anything. The modules load correctly, but nothing is rendered. Another downside is that the regionManager instance would get instantiated twice, but that's easily solvable:

public Orders(IRegionManager r)
{
       if (_regionManager == null)
       {
              _regionManager = r;
       }            
       InitializeComponent();
}

 

I know it's preferable to keep the view's code-behind as 'clean' as possible, but that can also be solved by making all views inherit a main app view where all this IModule management can reside, no? (Please correct me if I'm wrong)

Also, IF it is feasible to have the XAML code-behind as the Module itself, what needs to be done in order for the module to render and actually show? Or perhaps it should and I'm doing something wrong...

So if it's feasible, are there any 'bad practice' warnings anyone can shed some light on that I'm not aware of?

Thanks in advance.

Oct 20, 2010 at 4:52 PM

Hi,

I am not aware how the Jeremy Likness' example works, but probably is not trying to demonstrate the Prism modularity concept in a complex scenario.

In Prism modules are a set of related concerns. From the documentation on MSDN: A module can include a collection of related components, such as features, views, or business logic, and pieces of infrastructure, such as services for logging or authenticating users.

It means that modules are not strictly associated to only one view, but also they contain more than one view, services and so on. For example, an scenario might require to create a module with no views, since it only provides services.

Although in modules you will commonly find views, modularity is used for composing a complete logical unit in your application. For more information on this topic, you could take a look at the following documentation section on MSDN: Modularity

You could think the class that implements IModule as the initialization class of a module. In this class you will add/register views in a particular region, register your services in the container, etc.

Additionally, a more complex scenario of the aforementioned concept is implemented in the Stock Reference Implementation, so you could check this application.

Something that you can find interesting is that if you use MEF for modularity in Prism v4, it is not strictly necessary to create a class which implements IModule. This is because views, services and other types are discovered through declarative attributes. 

Hope this helps.

Fernando Antivero
http://blogs.southworks.net/fantivero