Splitting application layers into different assemblies

Question

There is a debate going on at my company. Some are advocating moving business, data and business entities in one assembly for

• Discoverability purposes. make it easy to find what you're looking for.
• Reduce the number of dll's we need to add to a project for development

Others citing the application architecture guide want each layer and business entities in a separate assembly.

Please note that

• Our business and data layers both consist of com + components.
• Our current hardware architecture has web, business, and data on the same box.
• SQL on a different box.
• We aren't currently using dll versioning because it's mostly useless with com+ anyways.

Some of use have a gut feeling that we should split our biz, data and entities but are short on reasons.

• Potentially reduce memory consumption
• Encourage proper architecture by only having business layer assemblies added to web projects. If the data services are also available then it makes it easy to do things the wrong way
• When we split our web server from the business and data layers we won't have to install crap we don't need from a god assembly.

Right now we have about 600 dll's in our system. So we are at one extreme where everything is split up. There is some definitely consolidation that can happen, but what is being proposed is taking us to a complete other extreme where every application is in one dll.

Could I get some outside perspective on this common issue?

Thanks!

Ewold

Answer 1

DLLs or assemblies are units of distribution.

1. If the code in a particular namespace or class is so tightly coupled with another namespace or class then it should be in the same unit of distribution. If the code in the foo.* file will never be used without needing the code in the bar.* file then you may as well build them into the same unit of distribution.
2. If a namespace or group of classes represents a reusable component (i.e. that code is being used in two or more products/applications) then it is a good candidate to be separately versioned and be its own unit of distribution.

For me it is primarily about cohesion, coupling, and reuse.
I like the classes in a particular unit of distributing to be cohesive, I dislike coupling between units of distribution (I would almost always prefer there to be dependencies on a third unit of distribution that contains interfaces such that the coupling is realised through dependencies on abstractions rather than concretions). Reuse is the key for me when making decisions about units of distribution. If the code is going to be used in multiple applications/products then it needs to be a separate unit of distribution with its own version number that is separate to the application version number.

Huda

Answer 2

Splitting on the physical deployment boundaries is a good idea. If you have components that can be hosted for remote usage, then a separate assembly makes sense. That's probably the easiest and most solid line you can split on, for starters. There are few cases when you want the web tier to include both the business services and data access code, for example.

From there, try to reduce the assemblies to things that make sense to version independently. If you always have to copy over 10 assemblies together, then they probably should be built as one.

Organizer

Answer 3

Our team's goal is to have as few assemblies as possible. In addition to the benefits which you list, I've also found that its easier to deal with DLL versioning nightmares when there is a smaller number of DLLs. Using an excessive number of assemblies also introduces the risk of creating circular references among assemblies.

We don't go out of our way to shove code into an assembly it doesn't belong in. But we definitely don't create a new assembly without a solid reason for doing so. Typically we have an assembly for the application's shared logic (business objects, etc) and an assembly for the user interface (the Web assembly, the WinForms assembly, etc). We also don't duplicate code/classes amongst assemblies just to avoid creating an new assembly.

Regular