Erwin van der Valk's blog: Practicing patterns : Design Patterns

Prism V2 – Drop 4

erwinvandervalk — Sat, 25 Oct 2008 01:54:53 GMT

Today, We have put an other drop of Prism V2 (Composite application guidance for WPF and Silverlight) online. You can download it from here:

http://www.codeplex.com/CompositeWPF/Release/ProjectReleases.aspx?ReleaseId=18750

New in Prism V2 - Drop 4

This sprint was mainly focused around UI Composition. We have ported the Region functionality from Prism V1 over so it also works in Silverlight. Then we also addressed a different style of visual composition, we’re calling Top Down composition. I’m going to drill into those composition styles later in this post.

Top down vs. Bottom up composition

In the last couple of weeks, we’ve had a lot of discussions around Visual Composition patterns.

Bottom up composition

Prism V1 used a regions to support Bottom Up composition. As a developer, you can define and name regions on your screen. When developing modules, you can use the names of these regions to push views into the regions. At first, we called this “push” based composition, because modules push their views into named regions. The diagram below shows an example of push based composition. We’re also calling this bottom up composition, because lower level modules push their views into the regions of higher level views.

Although this composition model allows for a highly decoupled and modular approach to UI development, we received some feedback that in some scenario’s it can be a bit to complex.

Top down composition

With top down composition we took a different approach. Usually, developers are very comfortable with the usage of UserControls. It’s quite common for developers to split up a view into several UserControls to reduce complexity (divide and conquer) and to improve reuse of visual elements. Now it’s quite easy to create controls and place them in different assemblies. However, in order to use those assemblies, the shell has to have a reference to the assemblies that hold the user controls. This goes against the principles of modular development where modules can be versioned, and deployed seperately.

We wanted to allow a model where you can visually compose your application in the same way as using UserControls, but without sacrificing modularity. To do this, we introduced a Top Down composition model:

So instead of the shell having a hard reference to the CustomerModule and putting a CustomerView directly on the ShellView, you put a ContentControl in the place where you want the user control. Then you use an attached property ViewType to specify what kind of View you want to display here, by specifying the interface of the view to display. The view interfaces can be defined in a seperate (Interface) module or in the shell.

When a module get’s initialized, it typically registers it’s views to the DI container. For example, the CustomerModule will tell the container that it can provide an implementation of the ICustomerView, because it registers the CustomerView type with the ICustomerView interface. Now after module initialization, the ShellView will ask the DI container for an implementation of ICustomerView. This will of course return the CustomerView, so it can then be shown in the ContentControl. Essentially, the ContentControl on the ShellView is pulling the CustomerView in from the CustomerModule, without having a direct reference to that module. We are calling this “Top Down” composition, because the Higher level modules define which views are displayed where.

This is an example (from the TopDownCompositionQuickstart) on how you specify a view that’s pulled into the shell in XAML:

<ContentControl 
    Regions:ContentController.ViewType=
         "TopDownComposition.Modules.Employee.IEmployeesListView, EmployeeModule.Silverlight, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />

You might notice 2 things:

The viewtype is a string
At first we wanted to use the type of the interface directly. Unfortunately, this doesn’t work in Silverlight, because you cannot create types in XAML, because {x:Type} doesn’t work. But working with strings isn’t too bad. We’re planning to make the resolving logic pluggable. This way, you could for example use logical names, exported by your modules, to identify and retrieve the views. In fact, the MEF framework also works like that.
The viewtype is a really long string
To make working with those really long strings a bit more bearable, we’re also thinking of building a custom type resolver. Since 99.9% of the times the full typename (Namespace.TypeName) is unique, you can get away with just specifying that and let the framework figure out which assembly the type came from.

We’re also considering moving the View resolving functionality from the ContentController to the RegionManager. Even though technically this has nothing to do with regions, conceptually it’s very similar. A region specifies where you want to display visual elements from other modules. In the top down approach, you specify the content via it’s interface and in the bottom up approach you give it a name so others can push views into it. But it’s still a placeholder for views.

Conclusion

Hopefully you’ve found this post useful in explaining what we’re building. As always, we are very open to feedback. If you don’t like something we do, please tell us! Also if you do like something, tell us that as well! It might just prevent us from changing something you are already happy with :)

Prism V2 (Composite Application Guidance) – Drop 3 is out

erwinvandervalk — Tue, 14 Oct 2008 23:19:54 GMT

Yesterday, we’ve put the third drop of the Prism V2 project (Composite Application Guidance for WPF and Silverlight) online.

You can download it from here:

http://www.codeplex.com/CompositeWPF/Release/ProjectReleases.aspx?ReleaseId=18184

In this blog post I’m going to answer the following questions:

What’s new in this drop?
What are the Prism V2 module loading scenario’s?
How is module loading implemented in Prism V2?
Why the change from module enumerators to module catalogs?

What’s new in this drop?

In this drop, we are starting to address Modularity. We’ve laid down the foundations for two new quickstarts: a static loading quickstart and a remote module loading quickstart. The most interesting of these two is the remote module loading quickstart because it does asynchronous downloading of modules from XAP files, and introduces a new XAML markup based way of defining modules.

Why address modularity in the third drop?

It might be interesting to address why we haven’t started to address modularity until this third drop. In the first two drops, we’ve mostly focused around multi targeting solutions between WPF and Silverlight. This might seem a bit strange, considering Prism is focused on composition. One of the goals of Prism V2 is to enable you to create applications that target WPF on the desktop and Silverlight from the browser using mostly the same codebase. we quickly found that targeting both Silverlight and WPF is not easy, so in true agile fashion, we tried to tackle this high risk unknown factor first. The added benefit is that we are dogfooding the tool we created to help multitargeting and can start capturing guidance on multi targeting applications early.

Prism V2 Module loading scenario’s

When designing the module loading strategy for Prism V2, we first had to come up with the scenario’s we wanted to address.

In a desktop application, you would typically want to create a modular application if you wanted to develop, version and deploy modules independently from each other. Of course these reasons are still valid for Silverlight applications, but we found that in Silverlight there is an other really important for creating a modular application: Minimizing download size. Especially on the web, users are very impatient. So you want users to wait for the minimum amount of time to start using your application. If you deploy your application in one massive 20 Mb Xap file, you are not going to end up with very happy customers.

So you could also use modularity to minimize download time. We defined three categories of modules for this: Core, background and On demand modules.

“Core” modules

There is going to be a group of modules that are the bare minimum for your application to run. Most of the time, this will be the shell, shared common infrastructure modules with shared services and one or more functional modules that the user absolutely needs to productively use the application. Of course, speed is essential, so you should try to keep these modules to the minimum size possible.

The core modules, will typically be packaged in the main Xap file. While this main XAP file is downloaded, you can use the built in Silverlight functionality to display a splash screen while the main XAP files are downloaded. Once the main XAP file is downloaded, the core modules will get initialized and the application will start up.

Background downloaded modules

Now there might be a couple of modules that are really important to your application, but the user doesn’t need them right away. However you don’t want them to wait for the module to get downloaded once they actually do need them. So to improve the user experience, you want to download these modules in the background. Modules will be downloaded in order and initialized when they are downloaded.

On demand downloaded modules

Then you might have a group of modules that are only used by a very select group of users (IE: an administration module). This will mostly help in minimizing the installation bandwidth used, because it’s not needlessly downloading assemblies.

Module loading in Prism V2

In Prism V1, there was no concept of module downloading, because all modules where assumed to be available on the file system. Now for silverlight, this approach only works for assemblies that are present in the main XAP file. In Prism V2, we want to support retrieving modules from elsewhere. We’ll support downloading XAP files for Silverlight, but nothing prevents you from downloading modules from the web or from a database in WPF.

This image displays roughly how the module loading pieces relate to each other:

The bootstrapper creates the Catalog and the Module manager. Then it kickstarts the modulemanager to start initializing the modules.
The Catalog holds a list of ModuleInfoGroups which is a collection of module info’s. We’ve created a grouping, to make it easier to define which containers (XAP files) hold which modules. It’s also a convenient way to create a group of modules that are ‘Core’.
The ModuleManager is responsible for coordinating the whole module retrieval and loading process. It will query the Catalog for core modules, background modules. It will also be the point where you hook up events to get notified when modules are downloaded.
The moduleManager has a list of ModuleRetrievers. We are likely to ship only one retriever: the XapModuleRetriever that downloads silverlight modules. However, this way you can plug in your own retrieval strategies (IE, load modules from a database, webservice or some other means)
If a module is present (either it was already on the filesystem, or it has been retrieved) the ModuleManager calls the ModuleLoader to instantate the module and call the Initialize method on it. This is the place where you can plug in your own module loading and initialization strategy.

Defining module information in XAML

One other new thing we are supporting is defining module information in XAML. This is different from defining module info’s from a config file, because loading the XAML actually instantiates the ModuleInfo files. This way, it’s easier to create your own ModuleInfo files and extend it with custom properties. Defining modules in XAML looks like this:

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

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

       3:                xmlns:Modularity="clr-namespace:Microsoft.Practices.Composite.Modularity;assembly=Microsoft.Practices.Composite.Silverlight">

       4:     <Modularity:ModuleInfoGroup Ref="ModuleY.Silverlight.xap" InitializationMode="WhenAvailable">

       5:         <Modularity:ModuleInfo ModuleName="ModuleY" ModuleType="ModuleY.ModuleY, ModuleY.Silverlight, Version=1.0.0.0" />

       6:     </Modularity:ModuleInfoGroup>

       7:     <Modularity:ModuleInfoGroup Ref="ModuleZ.Silverlight.xap" InitializationMode="WhenAvailable">

       8:         <Modularity:ModuleInfo ModuleName="ModuleZ" ModuleType="ModuleZ.ModuleZ, ModuleZ.Silverlight, Version=1.0.0.0" />

       9:     </Modularity:ModuleInfoGroup>

      10: </Modularity:ModuleCatalogBuilder>

      11:

This example (from the RemoteModuleLoading quickstart) has two XAP files. Each XAP file has a single ModuleInfo. These modules will be downloaded on a background thread and initialized when they have been downloaded (WhenAvailable)

Moving from ModuleEnumerators to Catalogs of modules

In Prism V1, we have the concept of module enumerators that define which modules are used by the application. For instance, the DirectoryLookupModuleEnumerator would find all modules in a specific directory. After many discussions, we found that this name is a bit confusing. If you think about it, an enumerator in .Net takes a collection and provides a way to walk through that collection. The prism ModuleEnumerators acted more like Module Info providers because they read module information from a certain location (IE: a directory or a config file) and returned the list of module info’s.

In Prism V2, we have defined the concept of a Catalog (of modules). A catalog contains the list of all the modules that are available to the application. Other components, like the ModuleManager can query the catalog for specific groups of modules. Like: “Give me all the Core modules”. Or “Give me all the modules to download in the background”.

Conclusion

There is a bunch of interesting stuff going on in this drop. We are still in the middle of a bunch of changes, but it does give a clear indication of the direction we’re taking.

As always, let us know what you guys think, either by commenting here, commenting on the CodePlex site, or by sending us an E-mail.

Thanks

Composite Application Guidance for WPF has landed

erwinvandervalk — Fri, 04 Jul 2008 21:03:00 GMT

My new colleagues at patterns & practices have just delivered a great new deliverable around creating composite applications in WPF. Check it out at:

http://msdn.microsoft.com/en-us/library/cc707819.aspx or at: http://www.codeplex.com/CompositeWPF

This deliverable contains:

Composite Application Library components.
Guidance around creating composite applications, including detailled descriptions of common UI design patterns.
Reference implementation
Quickstart applications that demonstrate specific aspects of CAL
Lots of hands on labs

Great stuff!