CODEWITHSUNDEEP
c#.net-assemblyorganization
Matt Whitfield
Matt Whitfield

Reputation: 6574

Is an assembly that contains a single class overkill?

I'm writing an app which plays host to a series of plug-ins. Those plug-ins generally use two libraries .Common and .UI which contain the interfaces that the plug-ins need to implement etc.

I am now at the point where I'm adding the capability for plug-ins to be subject to licensing. I have modified my host application such that it will only load plug-ins which define an interface instance (ILicenseInfoProvider) and export it through MEF. That bit is fine.

We have a selected provider of licensing code, and their licensing system involves use of a library. Now, I don't want to force each plug-in to be licensed through that system, and, by extension, require a reference to that system's assembly. So, I am planning on putting the code that references the third-party library in it's own assembly (something like .Licensing.Vendor). This way plug-ins can simply add a reference to that assembly, and include a class that looks somewhat like this:

[Export(typeof(ILicenseInfoProvider))]
class MyAssemblyLicenseInfoProvider : BaseVendorLicenseInfoProvider
{ 
    public MyAssemblyLicenseInfoProvider() : base("My Assembly's Product Name")
}

I'm reasonably happy with that set-up, apart from one niggling thing - which is that the .Licensing.Vendor assembly will only contain a single class, which is the BaseVendorLicenseInfoProvider relating to the specific licensing system in use.

So, after all that, my question is pretty simple:

Does it seem overkill to put that class in it's own assembly, or is the benefit of not forcing all plug-ins to hold a reference to the third party library worth it?

Upvotes: 4

Views: 121

Answers (3)

Peter Monks
Peter Monks

Reputation: 4389

It depends on what you are trying to achieve. Assemblies are a way of physically separating code whereas namespaces are a way of logically separating code.

Given that there can be a slight performance hit of loading too many assemblies (by which I mean a significant number, not just a few) then I suppose you could consider if it is possible to group as much as you can into one assembly but separate them by namespaces. But if you feel that it really does make sense to keep BaseVendorLicenseInfoProvider completely separate from everything else then I also do not see that as an issue.

At the end of the day it is all about what you feel is right, everyone has their own opinion of course but as long as what you have works for you then I don't see a problem.

Upvotes: 1

Rich O'Kelly
Rich O'Kelly

Reputation: 41757

At the moment there's a suitable purpose for the assembly - a publicly visible assembly for third parties to provide a means to interact via licensing. Seems perfectly reasonable to me:

  • even if there is only the one class currently, there may be more in the future
  • it's publicly visible, so you only want to provide only that which is necessary
  • it encapsulates a reasonable level of responsibility, namely licensing, without forcing specific implementations

Upvotes: 3

BugFinder
BugFinder

Reputation: 17858

I vote no, its not overkill, some plugins may not need a license, some may do..

Upvotes: 2

Related Questions