Module dependencies

Mar 29, 2012 at 1:45 PM

Hello,

I have two dependent modules, e.g. BLModule is using AuditTrailModule. To run my application, both modules have to be loaded, but for me it's irrelevant in what order they are initialized. Now I have two possibilities:

Solution 1: I can either set the dependency:

[ModuleDependency(typeof(AuditTrailModule))]
public class BLModule : IModule

Now, in my bootstrapper, I can add the BLModule to my module catalog and both modules are loaded due to the dependency.

Solution 2: Alternatively, I can remove the module dependency attribute and instead in my application add the BLModule and the AuditTrailModule to the module catalog.

The MSDN documentation says: "Modules may depend on other modules. If Module A depends on Module B, Module B must be initialized before Module A." As said, in our case it's only necessary that both modules are loaded, but the order of initialization is irrelevant.

Solution 1 has the advantage that our customer doesn't need to care about the AuditTrailModule, it get's automatically loaded when the BLModule is loaded. On the other hand, Solution 2 has the advantage that if our customer would want to implement its own AuditTrailModule, he could just do so an load it to the module catalog (the Solution 1 would unnecessarily still load the "old" AuditTrailModule).

Is there a guidance / best practice when to use dependencies? Should it be used to get the "dependent" modules automatically loaded, or should it only be used when the order of initialization matters?

Thanks for any help

Dani

Developer
Mar 29, 2012 at 5:52 PM

Hi Dani,

If I understood your scenario correctly, I believe that registering your modules in a configuration file or in a XAML module catalog would be an useful approach.

When using a configuration file or XAML module catalog you can define modules and their dependencies in a loosely coupled pattern (in fact, the Shell project wouldn't even need to have a reference to the modules.) This would allow you to add / remove modules and change their dependencies by simply modifying a couple of XML lines and without even needing to change the bootstrapper.

Prism provides different approaches to register modules and dependencies; which approach you should follow will depend mostly of your personal preferences and the requirements of your scenario.  You can find more information about this in the following chapter of the Prism documentation:

Also, regarding the first option, it seems that you are not exactly using modules dependencies: based on my understanding, if you know the AuditTrailModule type inside the BLModule module, that means that the BLModule has a reference to the AuditTrailModule; therefore, it seems that the AuditTrailModule is not being automatically loaded because it was defined as a dependency, but because of a strong reference in the BLModule. This would also explain why the loading order of the modules seems to be irrelevant to your application.

I hope you find this useful,

Damian Cherubini
http://blogs.southworks.net/dcherubini

Apr 3, 2012 at 11:47 AM

Hello Damian,

You're right, the BLModule has a reference to the AuditTrailModule. But we still need the AuditTrailModule to be loaded that it will be "initialized". So it can be loaded either by adding it to the config or by setting it as dependent module. And as you write, since we already have a reference to the AuditTrailModule, setting the module dependency attribute is probably the better solution.

Thanks for your answer.

Dani