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!
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
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:
I found an interesting article on the importance of structure (Whether a Project or Folder) within applictions. I will say that when you open a solution and see a list of Projects there names give me an indication of how the application was built. Etc
(MVP Design Pattern example)
Directory Structure Is Fundamental To Your Code
"As any designer will tell you, it is the first steps in a design process which count for most. The first few strokes, which create the form, carry within them the destiny of the rest." - Christopher Alexander
(Christopher Alexander is an architect. Without having worked as programmer, he has influenced many people who think a lot about programming. His early book A Pattern Language was the original inspiration for the Design Patterns movement. He has thought long and hard about how to build beautiful things, and these reflections seem to largely apply to software construction as well.)
In a CBC radio interview, Alexander recounted the following story (paraphrased here): "I was working with one of my students. He was having a very difficult time building something. He just didn't know how to proceed at all. So I sat with him, and I said this: Listen, start out by figuring out what the most important thing is. Get that straight first. Get that straight in your mind. Take your time. Don't be too hasty. Think about it for a while. When you feel that you have found it, when there is no doubt in your mind that it is indeed the most important thing, then go ahead and make that most important thing. When you have made that most important thing, ask yourself if you can make it more beautiful. Cut the bullshit, just get it straight in your head, if you can make it better or not. When that's done, and you feel you cannot make it any better, then find the next most important thing."
What are the first strokes in an application, which create its overall form? It is the directory structure. The directory structure is the very first thing encountered by a programmer when browsing source code. Everything flows from it. Everything depends on it. It is clearly one of the most important aspects of your source code.
Consider the different reactions of a programmer when encountering different directory structures. For the package-by-feature style, the thoughts of the application programmer might be like this :
"I see. This lists all the top-level features of the app in one go. Nice." "Let's see. I wonder where this item is located....Oh, here it is. And everything else I am going to need is right here too, all in the same spot. Excellent." For the package-by-layer style, however, the thoughts of the application programmer might be more like this : "These directories tell me nothing. How many features in this app? Beats me. It looks exactly the same as all the others. No difference at all. Great. Here we go again..." "Hmm. I wonder where this item is located....I guess its parts are all over the app, spread around in all these directories. Do I really have all the items I need? I guess we'll find out later." "I wonder if that naming convention is still being followed. If not, I will have to look it up in that other directory." "Wow, would you look at the size of this single directory...sheesh." Package-By-Layer in Other Domains is Ineffective
If you only ever have one application, than one project is fine. But I think that's very rare. Most of the time you will have multiple applications, so by having multiple projects you can reuse components between the applications without having to do hacky things like sharing source files.
Because of separation of concerns. This will greatly help unexpected references between classes/objects.
For WPF/Silverlight programmers, think about the MVVM design pattern: separating ViewModels and Views into two distinct projects will ensure there is no reference of a View object into a ViewModel.
Another point is the build time that could be shorter as the whole solution won't be recompiled each time. Might be a good argument for your manager (but this assumption might be wrong depending on the size of your solution).
Use different projects, if you need
Separated binaries for your solution, so you're flexible in patch/updates preparation and deployment
Possibility to manage plugins
Use of, for example, C++ codes inside your C#.
Reusable components use. The types declared in assemblies can be reused in different applications of your company to provide uniform API.
