The Ultimate Visual Studio Solution Structure

Question

Realizing that this could be subjective based on the project at hand, I\'m looking for the \"best practice\" method of structuring a VS (Visual Studio) Solution.

Ple

Answer 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).