Question

I have an windows application that is tightly coupled with a third party COM Object. And through the instance of this com object, all i am doing is create, delete, save and export. Now as new requirement arised, I have to add another similar third party component but from different vendor.

I dont want to write separate application that is similar to the first one except third party dependency changed.

How should i change my windows application so that

1. I can easily switch these third party dependencies. (like loosely coupled kind of thing).
2. I dont need to maintenance separate code.

I need some directions.

Answer 1

One option (which may not be suitable for you) is to write an interface that all plugins will inherit, which contains the abstracted-out methods of what you need to achieve from each COM .dll. Then, each plugin is a C# Class Library which implements the interface, and passes off all of the calls to a Backend COM object.

This means that you would ship 3 new DLLs, the one that contains your interface (and is referenced by the main application and the .NET Class Library), the .NET Class Library as the main ‘Plugin’, and then the backend COM .dll also.

Like I say it’s just one way to do it, but would get you up and running pretty quick with little overhead IMO.

---

Simplistic example:

IPlugin.cs [IPlugin.dll]

interface IPlugin
{
    bool MethodReturningTrue();
}

YourPlugin.cs [YourPlugin.dll, references IPlugin.dll]

class YourPlugin : IPlugin
{
    public bool MethodReturningTrue()
    {
        return true;
    }
}

PluginHost.cs [yourapp.exe, references IPlugin.dll]

class PluginHost
{
    public static IPlugin GetPlugin()
    {
        Assembly asmbly = Assembly.LoadFrom("YourPlugin.dll");
        Type objectType = asmbly.GetType("YourPlugin");
        return (IPlugin)Activator.CreateInstance(objectType);
    }
}

PluginUser.cs [yourapp.exe, references IPlugin.dll]

class PluginUser
{
    public bool GetTrueValueFromPlugin()
    {
        IPlugin pluginObj = PluginHost.GetPlugin();
        pluginObj.MethodReturningTrue();
    }
}

Of course, that relies on the class being called “YourPlugin” within the “YourPlugin.dll”. In a production environment to support multiple .dlls you would enumerate the .dlls, load each assembly, and use Reflection to find classes within that Assembly which implement the IPlugin interface. If you need two way communications between the plugin and the host, you can make another interface (ie. IPluginHost) and add a method to IPlugin which accepts an instance of IPluginHost. The implementing classes can then store that instance and call methods to have the two way comms in place.