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