开发者

Design Pattern for Installed module based application

开发者 https://www.devze.com 2023-03-07 02:53 出处:网络
Can someone point me in theright direction as to what sort of design patterns I should be looking at.

Can someone point me in the right direction as to what sort of design patterns I should be looking at.

There is a base application, and we may have more than one business module developed. Each module is developed independently, and there is a requirement to merge these modules into one application. The modules may also need to interact with each other.

So there can be several combinations, and maintaining each combination is just not possible in the long term.

I have identified the interaction between modules, and was thinking of separating them using开发者_Go百科 abstract classes. Which means that when I do merge 2 modules, I just need to copy the derived classes across, and they should just work. Is there a name for such a design pattern?

Are there other design patterns which could benefit me?


Easy.

Plugin system:

  1. Create an IApplicationHost interface which defines a set of base methods (like a Resolve and Register methods a la inversion of control / dependency injection).
  2. Create a IPlugin interface which has a Setup(IApplicationHost host) method. Each plugin use it to setup the plugin.
  3. Add a Start method to IPlugin too.

3) is needed since plugins can be dependent of each other. You first call Setup for each plugin to let them register their interface implementations etc. Next thing to do is to traverse all plugins again to call Start method for each.

All plugins are loaded by using Assembly.Load. Simply name all plugins like plugin_XXXX.dll to be able to identify them easily.

Plugin architecture

Since plugins can be use each other you need some way to support that. The easiest way is to use the Separated Interface pattern which means that you place all domain objects and service interfaces in a separate assembly. This also makes it far easier to keep backwards compability when releasing new versions of plugins. Simply never change the interfaces, extend them instead.

Then create a class library for the actual plugin. It should be dependent of it's own interface assembly, the applications assembly and all specification assemblies of the plugins that it's dependent of.


Plugin will allow a host application to dynamically load functionality (conforming to an interface) in seperate modules.

If you are developing for windows in .NET winforms, suggest you look at the Smart Client Software Factory

0

精彩评论

暂无评论...
验证码 换一张
取 消