Splitting assemblies - finding the balance (avoiding overkill)

I'm writing a wide component infrastructure, to be used in my projects. Since not all projects will require every component created, I've been thinking of splitting the component into discrete assemblies, so that every application developed will only be deployed with the required assemblies.

I assume that creating an assembly has some storage overhead (the assembly's code, wrapping whatever is inside). Therefore, there must be some limit to the advantage gained by splitting an assembly - a certain point where splitting the assembly is worse than开发者_开发技巧 keeping it united (storage-wise and performance-wise).

Now, here is the question: how do I know when splitting an assembly is an overkill?

P.S I guess there are other overheads to assembly splitting, aside from the storage overhead. If anyone can point out these overheads, it would be much appreciated.

There are indeed other overheads to splitting assemblies:

• Longer compile times (the more projects you have in a solution, the longer it will take)
• Deployment nightmare - especially updates to core components
• More assemblies may end up slowing your applications

Why do you need to split them out? To keep them logically separated? If that's the reason, use namespaces and not split assemblies.

Robert C Martin (well known for the SOLID principles) presents a packaging rule of thumb that you might find helpful:

"The granule of reuse is the granule of release."

That is to say, when deciding how to group things in packages, split them up how you would want to use them. So, if you would want to use one class in an assembly, you should want to use most of them. If everything in your project is for the same specific purpose, then why split them up?

I wouldn't worry about overhead from splitting up the assemblies. It isn't going to be significant and any performance hit will be more than paid for through simplicity of the application development process. What you need to think about a bit is versioning the assemblies and how you're going to deal with upgrades to application A when application B requires parts of application A. There is no quick fix to that problem and if you're not careful you might end up with internal branches of each assembly for each application which uses it.

Hm, this is really not a question that can logically be answered - there is no "rule" for that. Try to keep subsystems in seaprate assemblies. Sometimes there are technical reasons / deployment differences (assemb,y design assembly - which has to go into the GAC for Visual Studio to find the designers).

In general I keep them separated if I find logical subsystems that I also am testing separately. Note that the "internal" access only works on assembly borders. So, if you have a subsystem like a DAL.... having it in a separate assembly allows it to use "intern"l properties and be safe from simple abuse by developers in other parts of the project.

Also, if you go more "formal" different subsystems will have different owners / development cycles / program managers.