Alex Rivera | Logout

The Ultimate Visual Studio Solution Structure

Asked 2010-08-18T20:19:20.877
52

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.

Please feel free to edit this, comment on what you think might be incorrect, suggest alternatives, etc. I'd love to see this Community Wiki grow into a great resource for people just starting with VS Solutions.

Below is what I have working for me now (on my current project), however I know for a fact that there is some stuff in the wrong place. In my scenario, I'm building a Web Application using MVC 2

Please post your idea of the ultimate solution structure so that we can get an idea of the "best way" / "best practice" (whatever that means exactly)

IE:
How do you break up your DAL (Data-Access-Layer) / BLL (Business-Logic-Layer)?
Do you put your repository layer and service layer inside your BLL? If you're using MVC (Model-View-Controller), do you keep your controllers in the UI instead of the Core?
Do you throw lots of stuff in your Utility/Miscellaneous folders, or do you break it apart even further?
etc...

  • MySolution
    • MySolution.Core
      • Authentication
        • this is where I have a POCO and a method to searialize the poco into the userData secion of the auth cookie
      • Base
        • here is where I keep my BaseController and by BaseGlobal
      • Controllers
        • all of my controllers (obviously)
      • Domain
        • DatabaseModels
          • contains my L2S .dbml file
        • JsonModels
          • models used to pass JSON objects to th
.net visual-studio projects-and-solutions
Edit
Report

2 Answers

9

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.

answered 2010-08-18T22:01:45.660
7

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.

answered 2010-08-18T21:54:14.233

Your Answer