Nice Wiki.
I am starting a new project, and this is the structure I started with.
This follows from Microsoft best practices (business, data, services, presentation).
In my solution:
- Business: domain / project-specific logic, and above all, POCO.
- Data: repositories. self explanatory.
- Services: logic on top of repositories. I can add caching, filtering, etc. here My user interface communicates with the repository through services, and not directly to the repository. (one-to-one dependency for the user interface).
- Presentation: MVC Application (TBD).
You will notice that I also have the habit of prefixing the project assembly name using FQN.
I just like its appearance, plus in Object Explorer everything looks beautiful and "looks like a tree."
I also have the habit of putting a number in front of a folder, so it is sorted according to "what need what". In other words, it all depends on the business level (therefore, it is on top), the repository depends only on the business, the services depend on the repository and business, the presentation depends on the services and business, etc.
Of course, the above is the starting point. All I have now is a repository that returns users and services that apply logic on top of it (filtering).
In the end, I will have more business projects, more repositories (one for each logical area of ​​the web application), more services (external APIs, integration), and, of course, I have nothing in the presentation (im doing TDD).
I also like to have dependencies 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 user interface features.
For test projects - I have a project project for a draft solution.
What are my two cents (what it costs).