What to put in which library?

Question

I'm just starting out refactoring my code into multiple assemblies, and feel a bit lost on what to put where and how to name them. Up to now I've just placed all common classes in a single library, but it's time to advance on that.

So a few examples/questions to get my head started:

1. Two classes, IMessageBus and MessageBus, which is generic EventAggregator that allows subscription and publishing of messages of any type. Can be used of any project. Where to put these classes? What to name the libary, and what else would belong in that library?

2. What about modules of extension methods of common .net types, would you put all these in a single library?

3. Perhaps I'm lost on exactly what justifies to move something into a library or not, I'm basically just thinking "reuse". So if some more intelligent brief rules could be noted, would be helpful.

---

EDIT:

Yes my reasons are kind of vague, that's why I look for advice. Of course one common library satisfies reuse, so there should be other justification. I'm making a handful of applications that all use the same common library. One app will be distributed to external users, and hence I must force them to update when I find bugs. For this reason I thought sometimes I may be unable to know if a bug affects that program, as I don't remember exactly what part of the common library is utilized. So if I instead have many smaller libraries, it may be easier to identify which programs are affected, to avoid pushing unnecessary updates. (?) Btw I'm not programming for costumers, so I manage all distribution myself.

Answer 1

I generally try to keep things in the fewest number of assemblies as possible, but there are a few important reasons to split assemblies.

When I write a client / server solutions I will generally have 3 assemblies, one for client, one for server, and a 3rd project that represents objects shared between both. Both client and server will have a reference to the shared project, but not each other.

Another reason I have split assemblies is to allow other users to extend my work. In this case I will have the main project with the guts of the code in it, and a 2nd project that exposes the interfaces and base classes that 3rd parties use to write "plugins" for the main application. This allows the 3rd party to just reference the interface assembly without needing access to the main one.

Answer 2

Put things into libraries of related components if you are going down this path. However be wary of splitting things just to split things. You didn't mention why "it's time to advance on that". What specific gain are you seeking? Is the common library getting "too big"? Are there pieces you want to expose to an external organization without giving them the whole stack? Is deployment an issue because of the amount of applications that need to be patched?

Grouping things in a related manner is a good generic rule of thumb, but without knowing the reason for the split, that's about all you're going to get. :)

Expanding upon new information: For this reason I thought sometimes I may be unable to know if a bug affects that program, as I don't remember exactly what part of the common library is utilized. So if I instead have many smaller libraries, it may be easier to identify which programs are affected, to avoid pushing unnecessary updates.

Physical separation is probably not going to help you all that much with the above. It seems to me that if "finding which part" is the real cause for concern then within your library you are violating the Single Responsibility Principle (SRP), you are probably also not coding to interfaces or using unit testing.

The use of namespaces in an assembly give you as much separation as you need as far as organization is concerned. In my opinion the reason to break things up into class libraries is primarily for sharing, patching, and hiding things (via internal) that you don't want anyone else touching. Granted, if you have bits of code that exist in program A but not B, that's a pretty easy candidate for separation.

Answer 3

Only split when you need it.

As with naming types, variables, files, etc: do not create it if you do not know how to call it. It is a sign of not knowing what it is and what its purpose is.

Reasons to split are: separate versioning, separate deployment and hiding types using 'internal'

Answer 4

Try to group them by similar purpose. For example, you could put all of the messaging stuff in one dll called YourCompany.Messaging.