Strategy in developing Modular application

[Derek]

Hi All,

I am developing a Windows based application that consists of several
different modules. These modules are effectively separate from each other
yet share information in a common database. I would like to be able deliver
specific modules depending on what the needs of the client are. Some
clients may only need Module A and B, while others may need the
functionality in Module D.
What I am trying to figure out is the best way to go about designing a
modular application? Do developers generally ship modules as separate
libraries? If so, what is the best way to see if another module is
installed? A registry key perhaps? I am in the planning stages now and
would be grateful for any suggestions. Thank you.

- Derek

 

[Jay B. Harlow [MVP - Outlook]]

Derek,
I would recommend a Plugin pattern:

http://www.martinfowler.com/eaaCatalog/plugin.html

Basically how TraceListeners are implemented in the Framework.

Each 'module' is located in its own class library. One or more classes in
each library implement a specific interface (IPlugin for example) The
specific interface can be either an interface or an abstract base class.

Within the app.config file (or web.config for web apps) have entries that
identify the plugins. Generally I use custom sections within my app.config
to identify the list of plugins. I either use a custom section handler to
read the list of plugins (or just one plugin). Or I use
NameValueSectionHandler. Inheriting from
System.Configuration.DictonarySectionHandler works well in that you can
override the KeyAttributeName & ValueAttributeName. I normally make
KeyAttributeName=Plugin (where Plugin is actually interface name) and
ValueAttributeName=Type. I will also use sectionGroups in my app.config to
help organize it. Within the value attribute I store the name of the class,
in the format 'namespace.class, assembly' as that's what GetType expects.

I will use System.Type.GetType on the above value attribute, giving me a
Type object. I then use System.Activator.CreateInstance with the above Type
object to create an instance of the plugin, this allows me to define
constructors to the plugins if needed. Because the plug in implements the
specific interface I get early binding.

For the project I am currently working on, even the UI uses plugins, the
main executable is a minimalist shell that just starts the plug in loader
code, which happens to be in a class library... The app actually has
different categories of plugins (data layer plugins, business logic plugins,
UI plugins). I use an abstract base class for each kind of plugin as the
abstract base class has the factory method to load & manage the plugins.

I organize my app similar to:
myapp.exe - the main executable
myapp.exe.config - configuration, list of plugins
myapp.framework.dll - contains the plugin interfaces
myapp.plugin1.dll - contains the first plugin

I've been considering defining a custom installer that would create the
respective entries in my app.config file for a specific plugin. This would
allow easier deployment. I would install the class library & run installutil
to have it register the plugin in the app.config. Its on my list to define,
I just have not got to it.

The publishers in the Microsoft Data Exception block may be a good example.

Hope this helps
Jay