Reputation: 331590
Say you are writing an app like Photoshop where you have effects (filters), etc, should one make each of these filters a separate assembly using a separate project?
The main idea is to have each of these filters as nodes, so think of it like:
sourceImage -> Sharpen -> Darken -> Contrast -> Blur ...
It seems to me that it would make sense to have dll files like:
[Filters folder]
Sharpen.dll
Darken.dll
Contrast.dll
Blur.dll
But it would be hard to manage them like that, and that would prevent me to use the internal
keyword for class members, right?
So right now I only have 1 dll for all filters.
What's the best practices for organizing assemblies?
Upvotes: 4
Views: 2060
Reputation: 380
Reasons to have separate assemblies:
Reasons to avoid separate assemblies:
I think this is something that comes with experience. My own experience has been that as I've matured as a .NET developer, I've become less inclined to create more assemblies unless there's a very compelling reason.
Upvotes: 5
Reputation: 4259
Patrick Smacchia author of NDepend tool suggest that the number of assemblies is kept low. Look here. This also implies to a certain level that you use NDepend to manage dependencies between namespaces. Also, compilation is faster if you have less assemblies and deployment is easier.
I would second Reed Copsey that DI (like StructureMap) solution could provide you with extensibility and testability if that's what you are after.
Upvotes: 6
Reputation: 564931
Having separate assemblies makes it much easier to add more without recompilation. In particular, if you use some type of DI solution (like MEF), you can load these assemblies at runtime and inject them into your program.
However, this will require that your main program exposes an appropriate, public interface, so the other assemblies can work with your types. Internal modifiers become trickier, since you'd have to set the internals visible attribute for each assembly you want to have access to your internals.
Upvotes: 0
Reputation: 351758
I think a better way may be to have a Filters assembly with Sharpen
, Darken
, Contrast
, and Blur
namespaces for the types in that assembly. It really all depends on how modular you need each bit of functionality to be.
Upvotes: 3
Reputation: 1504122
I wouldn't restrict yourself to one filter per assembly. You may well want to group assemblies which implement similar functionality - e.g. colour/contrast together, while keeping them separate from very different kinds of filters (e.g. edge enhancing).
Just one bit of anecdotal evidence: I've often seen applications be difficult to manage due to having too many assemblies. I can't remember ever seeing one which had problems because it hadn't split the assemblies up enough. I'm not saying it can't happen - just that I haven't seen it.
Upvotes: 8