views:

57

answers:

4

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.

+3  A: 

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.

Oded
Hello Oded and thank you for your answer. No, i'm not splitting to keep them logically seperated, i'm splitting because I want to keep the applications' sizes at minimum. For example: i'm creating a complex component which displays data from a certain sub-system, but only some of the applications i'm creating are using that sub-system, so i thought that there is no need for the other applications to be deployed with that component's code.
M.A. Hanin
+1, big time - there are good reasons to split assemblies, but the downsides always make me pause before doing it. See http://www.theserverside.net/tt/articles/showarticle.tss?id=ControllingDependencies. (Performance is the least important reason, I think, but interestingly, splitting into more assemblies can slow your application down even when the total size of the split assemblies is smaller than a single big one.)
Jeff Sternal
@M.A. Hanin - You will still need to deploy and load the dependencies, so you are not really saving on anything. Are your assemblies truly so big that you need to do this?
Oded
@Jeff Sternal - I was looking for that article in order to add a link :)
Oded
Oded, size is relative to the transmission medium (see my comment to klausbyskov - many times my code must be transmitted via some very slow communication system, such as 56K modems). Concerning dependancies: If these sub-system assemblies are independant, and do not refer to each other in any way, doesn't it mean that an application can be deployed with the assemblies it needs and nothing more?
M.A. Hanin
@M.A. Hanin - If what you want is to reduce the size of your assebmlies, the following article may help http://www.programminglearn.com/410/using-reflection-to-reduce-the-size-of-net-executables#
Oded
@Oded, thank you again, you've pointed some important issues, and the article should help me accomplish my main goal of keeping the assembly sizes low. You won't believe how painful are the scenarios I encounter here ins Israel :-)
M.A. Hanin
@M.A. Hanin - I _am_ surprised to hear about your constraints... I know the country too well, though having worked for some large organizations there I feel your pain ;)
Oded
+1  A: 

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.

stimms
+1  A: 

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.

TomTom
+2  A: 

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?

andypaxo