The Ultimate Visual Studio Solution Structure

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 f开发者_开发百科or 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 the veiw
      • Repositories
      • Services
      • ViewModels
    • Extensions
      • all extension methods
    • Filters
      • Action Filters
    • Utilities
      • Apis
        • all third party API code goes in here
      • Badges
        • badge calculation goes here
      • MailClient
        • send plain text or html email using the classes in here
      • RoutingHelpers
        • contains a class to enable lowercase routes
      • also contains things that I don't know where else to put... IE: HTMLSanitizer, custom HtmlHelpers,UserInfo helper (IP address, browser, etc), DataConverter, etc
  • MySolution.UI
    • App_Browsers
    • Assets
      • Css
      • Images
      • Scripts
    • Views
    • Global.asax - inherits from BaseGlobal
    • Web.config

Screen Shots

Please feel free to comment accordingly, or better yet, post your own version (answer) below. I know that what I've got isn't the best way.

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

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.

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.