The Ultimate Visual Studio Solution Structure

Solution 1:

Nice Wiki.

I'm starting a new project, and this is structure i have begun with.

It follows the Microsoft Best Practices (Business, Data, Services, Presentation).

In my solution:

• Business: domain/project-specific logic, and most notably POCO's.
• Data: repositories. self explanatory.
• Services: logic on top of repositories. i can add caching here, filtering, etc. My UI communicates to repository through Services, not directly to repository. (one-to-one dependency for UI).
• Presentation: MVC application (TBD).

You'll notice I also have a habit of prefixing the actual project assembly name with the FQN.

I just like the look of it, plus in the Object Explorer it all looks nice and "tree-like".

Also i have a habit of putting a number in front of the folder, so it sorts according to "what needs what". In other words, everything depends on the business layer (so its on the top), repository only depends on business, services depend on repository and business, presentation depends on services and business, etc.

Of course, the above is a starting point. All i have right now is a repository which returns users, and services which apply logic on top of it (filtering).

Eventually i'll have more business projects, more repositories (one for each logical area of web application), more services (external API's, integration), and of course i have nothing in Presentation (im doing TDD).

I also like having the Dependencies all in one place (project folder).

For extensions, i have one class (Extensions.cs) for each project. In other words, i am "Extending" the repository, or "Extending" the user service, or "Extending" some UI functionality.

For test projects - i have test project per solution project.

That's my Two Cents (for what it's worth).

Solution 2:

There is room for improvement.

Any of my solutions have 4 basic parts. The UI Layer, the Business Layer, Data Access Layer, and Utilities. Each part is a project.

My ultimate goal is to NEVER write code in more than one place but to reuse it.

UI and Data Access are obvious.

Anything specific to the project I am working on goes into the Business project.

The Utilities is what I call a common library. These are good helper functions that I can use in many projects. For example a function to aid in logging.

Solution 3:

Your solution/project structure looks pretty sound to me. If you've never taken a look at S#arp Architecture, you may want to. The main difference between your structure and S#arp's architecture is that S#arp's breaks out the Controllers, Services, and Repositories into separate projects. The main benefit of doing this is that it becomes easier to enforce boundaries on your dependencies (e.g. you won't accidentally access data access specific libraries from code in Core).

Other than that, your structure looks very similar to the one I tend to use for my projects. I also add an "Extensions" folder for extension methods, since those are sometimes hard to find a good place for.