We're about to start with a new software and there are mixed opinions on the organization of software. I'd be delighted to hear what others might have to say in regard to the presented options as well as what other consideration one might refer to when making such a decision.
- Hierarchical approach
- Interchangeable approach
Approach #1 would consist of a single solution in VS with a number of projects connected to it (such as Utilities, Service, Exporter, Gui etc.). Everything would be in a single collection and the same root directory (for the solution file) and subdirectories (for the project files), so to speak.
Approach #2 would be constituted primarily of a set of projects, not related to each other (other than the references, of course), while the solution's (or solutions', would we desire to create different setups for different deliveries) purpose would be solely to refer to the (external) projects collecting them in the GUI. There would be n+1 directories (one for each project's file and an additional one for the solution's file, or solutions' files later on).
We've discussed the matter and listed the advantages of each approach and, although agreed on the facts, the team's members are not on the same page regarding which one to choose. We're a very democratic organization, so the decision needs to be persuasive to everybody (or at least a vast majority) and there won't be any from-above order from the boss. There's no prior code base and the financial consideration needs not to be addressed.
Which approach is preferable? Which is more of a commonly applied standard in the industry? What considerations might one take to ensure the rigidity of the choice?
It's also fully possible that our current project will be subject to the situation described in this question – both being the one that "borrows" projects from elsewhere as well as being the one that the projects are "borrowed" from.
Best Answer
It depends... its all about dependency management.
You're going to have a lot easier time with a single solution. This is so you can simply reference the other projects within a project and it'll all build and will be up to date everytime. This approach doesn't scale though.
So the problem is entirely down to those pesky references. The biggest problem I found was that the paths to external references (ie not part of the solution) were relative. So your team members must checkout a library in the same position in the build tree as it was originally created. If you can live with this restriction, building individual projects will be viable.
However, today Microsoft is using NuGet as a way to deliver libraries to applications. You build a lib, package it as NuGet and deploy it to a server. Then, when an application wants to use this library, it will automatically fetch it. No more compiling, you can always get the latest version from the build server (you so have CI, if not - get Jenkins. OSS/free and awesome).
This means you can concentrate on your part of the application rather than the dependencies. It also means you'll be more likely to keep a good separation of concerns in these libraries.