The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

designing a plugin architecture

I'm creating a .NET application where I'd like the different pieces to act as plugins - ideally, have the application be assembled as a set of plugins on a core platform. I am wondering what frameworks exist out there that might make it easy for me to do so. I've heard a little bit about the Spring Framework (there's a version that's been ported to .NET that i'm considering seriously). Then there's also Microsoft's CAB, but I don't know how good that might be compared to Spring. Do you have any suggestions, or can you recommend any alternatives?

Sarge Send private email
Tuesday, December 04, 2007
Huh.  I thought .NET WAS a 'plugin' architecture.
Tuesday, December 04, 2007
I don't know if this will be "native" enough for you, but I've always considered Drupal's extensibility model to be pretty impressive.  I'd love to try something like this in .Net, though I think a literal translation would be challenging because of the static compiler.

If you know anyone with a copy of "Pro Drupal Development" laying around, it might be worth a look through this book just to see how they've implemented hooks for integration.

You may also find some good examples in some CRM systems.  These are usually more oriented to customization rather than "plug-in" / "add-in" stuff, but some ideas may carry over.

I'm afraid neither of these will be a framework you can download and start using, but that's the closest I'm aware of.
D. Lambert Send private email
Tuesday, December 04, 2007
.Net is natively a "plugin" architecture due to its support of interfaces. 

You can create an interface assembly then implementation assembly.  Add something in your config file that tells your application which implementation assembly to use.  Use reflection to create instances of the classes.  This allows your application to program to an interface instead of an implementation.

Cuyahoga is a perfect example application that utilizes Castle Windsor to support a "plugin" architecture.  Cuyahoga is a complex application so you may want to spend a few hours reading up on Windsor before diving into it.

Tuesday, December 04, 2007
.NET 3.5 will have a whole new set of namespaces/classes dealing with plugin/addin support for applications. I haven't looked at it yet but it might prove valuable.

Google for "System.Addin" and see the following article on MSDN:
Johnny Bravado
Tuesday, December 04, 2007
In the meantime, no need to wait for .NET 3.5. Look at examples like Drupal and Wordpress as well as a pure plugin architecture like Eclipse, which is probably closest to what you're envisioning for your product. You'll notice that the base system sits both above and below your plugins. So you need to answer some basic questions:

* What services will plugins provide to the base system? You should define a basic plugin interface plus interfaces for whatever data types plugins might be used to implement.

* What services will plugins provide to each other?

* What services will the base system provide to plugins? It's important to define that and stabilize that interface early if third parties will write plugins.

The actual plugin loading mechanism should be straightforward in .NET.
Tuesday, December 04, 2007
I just looked at the the 3.5 stuff -- pretty cool.  This looks like a nice foundation to build on, but I think a lot of the "art" of the plugin design will still come from where you provide your hooks -- after all, that's where you start to reflect the nature of your domain model.  I didn't see a whole lot of guidance for this in the framework ("all the add-in has to do is implement the methods defined in its abstract base class.")

Doing this right is going to take some combination of (1) a lot of foresight; (2) experience with other plugin-based apps, and (3) a chance to bloody your nose a few times with some sample plugins.

If you've got a prospective consumer in mind, let him help evaluate the API early and often to combat the scenario where an API looks great on paper, but feels like a straitjacket when you use it.

Good luck - sounds like fun.
D. Lambert Send private email
Tuesday, December 04, 2007
I'll add a +1 to the Drupal discussion.  I've been using it for 3+ years and it's pretty impressive/useful all the way around.
KC Send private email
Tuesday, December 04, 2007
er... I meant the plugin architecture specifically.  Including how they do permissions.
KC Send private email
Tuesday, December 04, 2007
Hey guys, thanks a lot for the responses. Helped me think through some of the issues involved. Will spend a few days looking at some of the projects mentioned (Eclipse/Drupal etc.).

Sarge Send private email
Wednesday, December 05, 2007
Another think you might want to look at is here:

#Develop is a C# IDE written in C#, and a large part of the architecture is plugin-based. The page has a download of a book describing how the #Develop code was designed and how and why it works the way it does.

I thought it was a pretty good explanation, and their system, while perhaps overkill for simpler applications, covers the space pretty well.
Chris Tavares Send private email
Wednesday, December 12, 2007
Sure a lot of .NET Cool Aid drinkers around these parts ;-)
Lord Byte
Friday, December 21, 2007

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz