There is a debate going on at my company. Some are advocating moving business, data and business entities in one assembly for
Others citing the application architecture guide want each layer and business entities in a separate assembly.
Please note that
Some of use have a gut feeling that we should split our biz, data and entities but are short on reasons.
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!
DLLs or assemblies are units 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.
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.
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.
The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.