5

As long as the code in the base library is as loosely coupled as splitting it up into separate libraries, what's the problem? In general, having a lot of assemblies composing a .NET solution is painful.

Plus, when code in one solution needs to be shared, it can just be added to the common library, rather than deciding which common library it should be added to or creating yet another library.

edit: the question comes to me after using Smalltalk for a bit, where all the code is available to use, all the time.

Improve this question

3 Answers 3

Reset to default
3

  • Security, versioning, and dependancies are a few concerns.

  • I like to keep code that references or imports other libraries (especially 3rd party libraries) as isolated as much as possible, not just logically, but physically too. These helps enforce/encourage logical concerns of cohesion and coupling.

  • Testing convenience. Load and execution time of a small assembly and corresponding test assembly vs a large assembly and a large test assembly.

  • Fragile or volatile aspects are easier to identify and focus on.

  • Extensibility and distribution. Interface only or interface primarily projects are nice for value added extension building. Why deploy a large component, when small is possible?

Improve this answer
1
  • You're right. Ugh, I guess no matter how much I want .NET to be Smalltalk, it just isn't.
    – xofz
    Commented Mar 8, 2011 at 0:33
3

There are 4 things to consider: separation of duties, importance, dependencies, and size.

Assemblies, folders/packages, classes, functions, blocks - they all have this in common.

A general rule for size of a given topic:

  • >1 class = folder/subfolder.
  • >5-10 classes = subfolders.
  • >15-25 classes = assembly.

My belief is the purpose of the classes is more important than the size.

A real life example:

I wrote a very simple command line parsing library. This ended up being 3 classes in a "CommandLine" folder in a common library assembly... it wasn't that important and I used it in two related projects.

Then I gave the source of those classes to help someone with their project. Someone else saw it and suggested I add attribute support. I took the opportunity to refactor the code, add unit tests, and make it a much more advanced library. When doing this, I moved it to its own assembly so I could work on it independently over several nights and because of its size, importance, and re-usability outside of my common library.

Why is having many assemblies painful in .net? I would say deployment and creating new projects are marginally more difficult with more references.

Just add an existing project to your solution and a "project reference" to your projects that depend on it. Done.

I could see a compiled assembly reference being a burden by having to build, copy, and test in each solution but you have the source so just add the project to your solution.

Improve this answer
1

I don't see a problem as long as the different libraries have relating objects in them. If they belong together, they belong together. No such thing as 'too big' in these cases.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.