Click here to Skip to main content
65,938 articles
CodeProject is changing. Read more.
Articles
(untagged)

Dynamic Modules with Prism and the Modern UI for WPF Toolkit

0.00/5 (No votes)
23 Mar 2016 1  
Prototype for a plugin architecture based on the Prism Library and the Modern UI for WPF (MUI) toolkit

Introduction

A little while ago, a colleague of mine told me about a problem he had to solve. A customer asked him to develop a desktop application that presents a different set of features in accordance to which of the enterprise offices is running the software. On the one hand, I remembered how to do that from a past project where I was involved. On the other hand, there is an open source project for creating WPF applications with a modern look & feel, which I am following since a couple of years because I think it's really great.

I wondered if there is a way to solve the problem by using Prism and the open source MUI library for creating a plugin architecture, and came up with a prototype solution which I am presenting here.

WPF Dynamic Modules Demo

Dynamic Modules is a sample prototype for a WPF modular application based on the Prism Library and the Modern UI for WPF (MUI) toolkit. It is a proof of concept for creating metro-styled, modern UI WPF applications in a plugin architecture.

Background and Requirements

The article assumes that the reader has at least a basic background on Windows Presentation Foundation (WPF), the Prism Library and the Unity IoC container. Visual Studio 2015 is needed to compile the project.

Architecture

The central ideas for the proposed plugin architecture are:

  • Put into a directory the desired project modules (or put them all and run a filter on loading time).
  • Dynamically load the project modules from the modules folder.
  • Each module exposes an entry point for an option in the main menu.
  • Dynamically build the main menu from the loaded modules.
  • The first option in the main menu is fixed and common for every user.
  • A core module with shared services, repositories, DTOs, data model definitions, etc. is statically loaded. It can be referenced by any solution project.

Dynamic modules are copied to a directory as part of a post-build step. These modules are not referenced in the startup project and are discovered by examining the assemblies in a directory. The module projects have the following post-build step in order to copy themselves into that directory:

xcopy "$(TargetDir)$(TargetFileName)" "$(TargetDir)modules\" /y

The solution is built into "..\bin\" folder.

Understanding the Code

If you check out the source code for MainWindow.xaml in the MUI demo project, you will see how the main menu is statically built:

<mui:ModernWindow.MenuLinkGroups>
    <mui:LinkGroup DisplayName="Welcome">
        <mui:LinkGroup.Links>
            <mui:Link DisplayName="Introduction"
            Source="/Pages/Introduction.xaml" />
        </mui:LinkGroup.Links>
    </mui:LinkGroup>
    <mui:LinkGroup DisplayName="Layout">
        <mui:LinkGroup.Links>
            <mui:Link DisplayName="Wireframe"
            Source="/Pages/LayoutWireframe.xaml" />
            <mui:Link DisplayName="Basic"
            Source="/Pages/LayoutBasic.xaml" />
            <mui:Link DisplayName="Split"
            Source="/Pages/LayoutSplit.xaml" />
            <mui:Link DisplayName="List"
            Source="/Pages/LayoutList.xaml"  />
            <mui:Link DisplayName="Tab"
            Source="/Pages/LayoutTab.xaml" />
        </mui:LinkGroup.Links>
    </mui:LinkGroup>
    <mui:LinkGroup DisplayName="Controls">
        <mui:LinkGroup.Links>
            <mui:Link DisplayName="Styles"
            Source="/Pages/ControlsStyles.xaml" />
            <mui:Link DisplayName="Modern controls"
            Source="/Pages/ControlsModern.xaml" />
        </mui:LinkGroup.Links>
    </mui:LinkGroup>
    ...
    ...
    ...
</mui:ModernWindow.MenuLinkGroups>
</mui:ModernWindow>

The main menu of the main window is a dependency property of the ModernWindow class, named MenuLinkGroups. It returns an instance of the LinkGroupCollection class, which inherits from ObservableCollection<LinkGroup>. That is, the main menu is an observable collection of link groups. Each LinkGroup represents an entry point to the menu. So, if each dynamic module has a way to export a LinkGroup instance, all we have to do is add it to the observable collection of link groups. That way comes under the form of an interface contract.

public interface ILinkGroupService
{
    LinkGroup GetLinkGroup();
}

The core module defines the ILinkGroupService interface. It states that if a module wants to plug an option onto the main menu, it can do so by implementing the GetLinkGroup() method, which in fact returns a LinkGroup instance. An implementation of the ILinkGroupService interface and the GetLinkGroup() method will look like:

public class LinkGroupService : ILinkGroupService
{
    public LinkGroup GetLinkGroup()
    {
        LinkGroup linkGroup = new LinkGroup
        {
            DisplayName = "Module One"
        };

        linkGroup.Links.Add(new Link
        {
            DisplayName = "Module One",
            Source = new Uri
    ($"/DM.ModuleOne;component/Views/{nameof(MainView)}.xaml", UriKind.Relative)
        });

        return linkGroup;
    }
}

Now, we need to be able to dynamically load the modules, create an instance of the ILinkGroupService interface for each module, and insert the exported option in the main menu. That is the function of the code implemented in the ConfigureModuleCatalog() method of the Bootstrapper class.

protected override IModuleCatalog CreateModuleCatalog()
{
    return new DirectoryModuleCatalog() { ModulePath = MODULES_PATH };
}

protected override void ConfigureModuleCatalog()
{
    var directoryCatalog = (DirectoryModuleCatalog)ModuleCatalog;
    directoryCatalog.Initialize();

    linkGroupCollection = new LinkGroupCollection();
    var typeFilter = new TypeFilter(InterfaceFilter);

    foreach (var module in directoryCatalog.Items)
    {
        var mi = (ModuleInfo)module;
        var asm = Assembly.LoadFrom(mi.Ref);

        foreach (Type t in asm.GetTypes())
        {
            var myInterfaces = t.FindInterfaces(typeFilter, typeof(ILinkGroupService).ToString());

            if (myInterfaces.Length > 0)
            {
                // We found the type that implements the ILinkGroupService interface
                var linkGroupService = (ILinkGroupService)asm.CreateInstance(t.FullName);
                var linkGroup = linkGroupService.GetLinkGroup();
                linkGroupCollection.Add(linkGroup);
            }
        }
    }

    var moduleCatalog = (ModuleCatalog)ModuleCatalog;
    moduleCatalog.AddModule(typeof(Core.CoreModule));
}

We first create Bootstrapper.ModuleCatalog as a DirectoryModuleCatalog and initialize the module catalog. Then iterate over the discovered modules. For each one, look for a type that implements the ILinkGroupService interface. If such a type is found, then create an instance and call its GetLinkGroup() method. The returned LinkGroup instance is then inserted into a collection which is passed to the Shell when it is created:

protected override DependencyObject CreateShell()
{
    Shell shell = Container.Resolve<shell>();

    if (linkGroupCollection != null)
    {
        shell.AddLinkGroups(linkGroupCollection);
    }

    return shell;
}

The Shell.AddLinkGroups() method is defined as:

public void AddLinkGroups(LinkGroupCollection linkGroupCollection)
{
    CreateMenuLinkGroup();

    foreach (LinkGroup linkGroup in linkGroupCollection)
    {
        this.MenuLinkGroups.Add(linkGroup);
    }
}

Where the CreateMenuLinkGroup() method creates the static common option of the main menu, and the foreach loop creates the dynamic ones. And that is all, folk. If some module, for instance ModuleOne, is removed from the modules folder, the main menu will look like:

Module one is removed

Alternatively, if ModuleTwo is removed, the main menu will look like:

Module two is removed

And obviously, if there is no module in the modules folder, only the static common option is accessible:

Both modules are removed

Conclusion

Prism Library offers a set of resources for creating modularized WPF applications. The Modern UI for WPF (MUI) toolkit offers a set of resources for creating nice and good looking UI for WPF applications. This article presents a way to mix both worlds for creating a plugin architecture. A related subject on authorization, that is, dynamically load the modules according to the user name or his role, so that user can only access authorized areas or features of the application, is out of the scope of the prototype project.

Surely, there is an alternative or even better approaches to doing such a mix so, please, feel free to comment and leave your ideas, suggestions and opinions. They are welcome!

Links of Interest

You may find complementary information at:

*Currently, there is no need to "implement" the IView interface in the view's code-behind.

History

  • 22nd March, 2016: Version 1.0 - Initial article submitted

License

This article has no explicit license attached to it but may contain usage terms in the article text or the download files themselves. If in doubt please contact the author via the discussion board below.

A list of licenses authors might use can be found here