Plug-in based development… and docking windows ala Visual Studio 2005 1

[d00ape]

I’m going to build an application that should be based on plugins that extend the core application with extra customer specific functions.

I like my plugins to have a common look, fell, and behaviour. I like tips on how to design my application to make it extendible. I like some tips on design patterns that could be useful.

I like to see my core-application as a framework for further development of plug-ins. I’ve read some articles on reflection and I get the point of it but I don’t really yet have the right thinking of how to apply common design patterns.

My other question is how I can get the look and fell of my plug-in dialogs like Visual Studios dockable windows. Is there any support for that in the .NET framework?

All tips on how I should start design my application and make it look good are welcomed!

 

[JurkMonkey]

The 2.0 Framework contains a lot of those dockable controls. You can also purchase them from other 3rd party companies.

In terms of plugins, you generally create a separate project that contains only interfaces or a base class type. Generally interfaces is better!

Then that project can be compiled as a class library (DLL) which other projects can use to create their own compatible dlls. I tend to take each of these DLLs and put them into a specific folder. Then get all the files from that folder and create a specific instance of each item.

for example: say I'm writing a drawing application. the application contains "tools" which are used to draw things on the screen. So you might create an interface in your seaparate project called iDrawingTool.

then in another project called RectangleTools you would create a RectangleTool class that uses the iDrawingTool interface. Compile the dll and stick it into a "Tools" folder in your main projects bin directory (or anywhere common for that matter)

then when your Drawing application loads, you find all the tools in the Tools folder and create instances of iDrawingTool. (Activator.GetInstance(...))

Now your application is purely a framework and will only be functional if there are tools available in that folder. You can then distribute other tools very easily over time. Just create a new project and develop the new tool - when its done, drop it in the tools directory and you're done.


In terms of design patterns, ensure that you are using Model View controller wherever possible. This allows your code to be managable and scalable.

I hope that gets you started.

 

[d00ape]

Thanks for all your suggestions! You have gave me a lot to think about. I'm quite well known with MVC and the observer pattern but I've never implement any of those in C#.

One of my core functions in my small Cad-application will be to select objects. My different plug-in tools will all do selections and also be notified about selections (that other plug-ins does). Is that an example of when I should use MVC?

 

[JurkMonkey]

If you're notifying all plugins of a tool change then yes - you could use MVC or some other type of Subscriber pattern. But I personally prefer to keep reference to all plugins accessible in my controller.