CODEWITHSUNDEEP
wpfinversion-of-controlunity-containerprismcontainers
Edward Tanguay
Edward Tanguay

Reputation: 193322

How can I loosely reference modules in Prism so they can or cannot exist?

In this stackoverflow question I learned that Prism/Unity is not as decoupled as I thought, e.g. if I have this class which gets menuManager injected into its constructor, then I have to make sure that this class actually exists somewhere (I thought that you could just pull the .dll that contains the class and the container would deal with it, e.g. injecting a null in its place):

public class EmployeesPresenter
{
    public EmployeesPresenter(IMenuManager menuManager)
    {

    }
}

But I can deal with that: the application cannot run without a MenuModule (or else as was suggested I could have a NullMenuModule which does nothing but keeps the application from breaking).

However, the application I am building will have a MenuManager class in the MenuModule and every module will have to register everything it wants to have in the menu with the MenuManager. However, I want to be able to swap out MenuModules e.g. have a InfragisticsMenuModule and have a TelerikMenuModule, etc.

However, when I am in e.g. the CustomersModule, in order to use TelerikMenuModule, I need to reference it. And when I want to use InfragisticsMenuModule, I need to reference that.

So how will I be able to "hot swap" TelerikMenuModule with InfragisticsMenuModule without recompiling all my modules with new references, e.g. I want to replace this:

Application.exe
Customers.dll
TelerikMenuModule.dll

with this:

Application.exe
Customers.dll
InfragisticsMenuModule.dll

and simply be able to restart the application and it runs with the new InfragisticsMenuModule.dll and does not complain that TelerikMenuModule.dll no longer exists.

Upvotes: 2

Views: 1227

Answers (2)

Jimmy Chandra
Jimmy Chandra

Reputation: 6580

For obvious reason MEF comes to mind here and is designed for stuffs like this. I haven't had a chance to use Unity, so I'm not sure if it has something built in like this (i.e. scanning a directory for an IMenuModule implementation), but MEF can do this.

Suggestion also is to put this IMenuModule in a common assembly (separate from your other assembly). I usually called this thing Something.Core.dll.

So you might have: Application.exe, Customer.dll, Application.Core.dll, and your specific MenuModule implementation.

Your specific MenuModule implementation will reference the Application.Core assembly to gain access to its IMenuModule interface and implement it there.

Upvotes: 2

Daniel Earwicker
Daniel Earwicker

Reputation: 116674

This is where interfaces come in. You need something like:

public interface IMenuSystem
{
    // whatever operations need to be offered by a menu system
}

Application.exe and Customers.dll may only refer to that interface. They aren't allow to know about a specific implementation.

Then you would use configuration steps (calling Register... methods or using a config file) to specify which type will provide the implementation of MenuSystem.

Upvotes: 5

Related Questions