What are the benefits of multiple projects and one solution? [closed]

Question

When I was working in enterprise, we used multiple projects in the solution - projects for UI, business logic, data access, database and printing. Now I'm in a new enterprise and the manager tells me that I don't have to make all these projects, but that I have to make them into seperate directories in one project in the solution.

I just want to know if I have to convince him to use multiple projects!

Answer 1

I'm very surprised by the accepted answer. I've worked in both environments and have found multiple projects to be beneficial overall. The actual decision is still up to your team (if a single project isn't preventing you from achieving your goals then it's sufficient).

I lean on Uncle Bob's Principles of OOD regarding package management. These aren't very well known (especially compared to his SOLID principles for class design) but they are sensible.

Taken from Uncle Bob's Principles of OOD

The first three package principles are about package cohesion, they tell us what to put inside packages:

• REP The Release Reuse Equivalency Principle The granule of reuse is the granule of release.
• CCP The Common Closure Principle Classes that change together are packaged together.
• CRP The Common Reuse Principle Classes that are used together are packaged together.

The last three principles are about the couplings between packages, and talk about metrics that evaluate the package structure of a system.

• ADP The Acyclic Dependencies Principle The dependency graph of packages must have no cycles.
• SDP The Stable Dependencies Principle Depend in the direction of stability.
• SAP The Stable Abstractions Principle Abstractness increases with stability.

These align with my personal experience in which leaning towards fewer projects has frequently resulted in problems in my experience:

• Fewer packages can result in poor dependency management. Seperate projects/assemblies can help keep internal/private classes and members from being used where they shouldn't be

• Typically with many projects you develop a very stable and tested "core" set of libraries, which very rarely change. Keeping these components in their own project (or even solution) can help insulate them from ongoing changes in the higher-level layers.

• The large projects that result from using fewer (or a single) project can be very unruly. Visual Studio does not set the expectation that your Project/Solution mirrors your file structure, so an organized large project can still exist as chaos on your drive.

• Visual Studio is smart enough to avoid recompiling assemblies which have no changes. As your "core" projects stabilize they will see fewer compilations, which can save time compiling.

• Likewise with above, using fewer projects leads to always recompiling code--whether or not it has relevant changes. A one-line change in a very large project will result in full recompilation.

Of course multiple projects can have their issues as well:

• You have to be consciencious of your dependencies in order to avoid cyclical references (which .NET handles fairly well, but Visual Studio works to prevent)

• Your solutions may become large enough to warrant sub-solutions, which can be tricky to manage

• Initial compile times of a solution may be slower

And finally, one rarely used feature in .NET is that a single .DLL can contain multiple Modules (effectively it's several assemblies sharing a single set of metadata). I wouldn't suggest using this, but it's interesting to know it's how things work: http://www.codeproject.com/Articles/9364/Merging-NET-assemblies-using-ILMerge

Answer 2

I actually agree with your manager.

Multiple projects means multiple assemblies, lots of copying around of assemblies, and generally slower compilation times.

If your only reason to have multiple projects is improved organization, then you are doing it wrong. It would be just as effective to use folders.

Some valid reasons for having different assemblies are:

• You have a plugin architecture
• You need to deploy assemblies separately
• You need to work in multiple languages
• You are creating libraries to be used in different places