Strategy tips on partitioning assemblies and namespaces

Question

A very common complexity for technical architects is to divide the application in assemblies and namespaces.

• Assemblies can be partitioned according: deployment, performance and security boundaries.
• Namespaces can be partitioned according logical application boundaries.

Also: namespaces can span multiple assemblies.

I had a bad experience in a project once where we partitioned assemblies according logical units of the application. This decision ended up with solution files with 30 or 40 projects! The master solution file loadtime was approx. 5 minutes!!! This ended up in a great waste of time, pff...

The opposite scenario was to hold all code in 1 assembly and partition when it is really needed.

Do you have additional tips or best-practices regarding this issue?

Answer 1

I split code into separate assemblies only when I need to reuse it for two different applications (pretty much). So I start with everything in one project, and when the need to reuse code becomes obvious I create a new assembly and move the code (sometimes its obvious from the very beginning, e.g. when you need to have a web app and win forms doing same thing).

Re. Namespaces, I prefer to have it quite well partitioned within an assembly, so it is clear where each class belong and what it should be used for.

Answer 2

You can partition classes with Namespaces and use folders if you want to group source files together for easier maintenance. If you have security requirements and certain assemblies need to go through special processing such as Obfuscation for example, then you may need to separate those to a separate project.

Re-usability is also a factor that you may need to consider when thinking about whether a logical unit needs to get its own project since you may need this project in another solution as well.

Answer 3

What has worked well for me is large level grouping by type of code, but more macro-level than the logical units you were splitting up by. For instance,

• Engine - anything non visual. Support classes, base infrastructure code. Everything refers to this.
• EngineUI - Relies on Engine, and obviously used for UI, but nothing specific to any one app.
• EngineServer - Relies on engine, used by the (usually web) server build.
• AppCore - App specific core functionality, no UI.
• AppUI - App specific UI
• AppClient - Uses AppUI, AppCore, EngineUI, Engine. The actual client app.
• AppServer - Uses AppServer, EngineServer, Engine. The server app.

Each project has a hierarchy of namespaces and once in a while I find its useful to fork out a large body of code into another assembly but usually these keep things reasonably organized and manageable, even when there are many hundreds of files involved. Too many projects is definitely something I try to avoid. One bonus of keeping these projects to a minimum is that it makes it a lot easier to actually reuse these libraries in subsequent projects (such as automated testing builds).

I don't worry too much about unused code being deployed from these libraries because I can use a utility that strips out unused functions for the final build, keeping file size down to a minimum.

Answer 4

I find it helpful to organise namespaces into a hierarchy, and make the assembly names match the subnamespace they contribute to. For example, a project called Womble would have a top-level namespace Womble, and then there might be assemblies called:

Womble.ClientLibrary.dll
Womble.Controls.dll
Womble.Util.dll
Womble.Interop.dll

Here, the outer Womble namespace spans multiple assemblies, but each assembly has a unique subnamespace that only it can contribute to, which you find by removing .dll from the end. It makes it a lot easier to remember what you need to reference and to find things.

As for very large numbers of assemblies, ultimately you don't need to keep them all in one solution. In large scale development it helps to break up a big product into subsystems, which may themselves consist of multiple assemblies, and each subsystem may end up being maintained by separate teams, and can have their own solution files. The various teams "release" new versions to each other via source control, treating each other as third party libraries.

I don't think there is a hard and fast way to decide how to break up software into aseemblies. There's a general principle here: things that change for different reasons should be separated.

Very large projects can gain from the fact that by putting things in separate assemblies, you are able to patch them separately. You can produce a hotfix for an issue in Womble.Interop.dll, and then separately produce a hotfix for an issue in Womble.Controls.dll, and give both to the same customer, so that in theory, those two assemblies could be completely maintained and supported by separate teams, without having to coordinate their activities directly.

Separate assemblies also create clarity in the dependencies between code. You can see at a very high level (just looking at the references list) how one chunk of code depends on another, and how it might be reused. If you put everything in one assembly, it might be one big tangled mess with no sensible pattern to it.