I believe your question boils down to:
What are the appropriate practices to organize the layers of these projects and the folders that separate the projects?
Breaking your question in two parts:
What are the appropriate practices to organize the layers of these projects?
It is necessary to understand why we use layers. Among the various reasons, I highlight some:
To lower the coupling between components (designs, dlls, etc.) and increase cohesion. (If these words don’t make sense to you, start by this link Patterns in practice -Cohesion and coupling
In addition, designing layers between components helps keep responsibilities separate correctly, meaning you keep things close that change for the same reason. (no typing sql inside the mvc controller, for example).
Last and most importantly, by mentioning appropriate practices the only thing I can tell you with any certainty is that a good design is always uncoupled. That is, don’t make your application totally dependent on WCF, or MVC, separate your business rule layer and protect it from those dependencies using abstractions). A short article that shows a bit about it Hexagonal Architecture (Ports and Adapters)
Lastly:
and folders separating projects?
This is a decision entirely of your team, in Visual Studio for example, when creating a folder in the solution it doesn’t even create it on disk, it’s just a visual organization. Be significant, choose good names that demonstrate your intention.
I could discuss this subject for much longer, but I think it involves the risk of me confusing you even more, I think you need to segment your question better, so it’s easier to attack the separate problems, without being too generic.
If you want to better understand what layers are and how to give good names, follow two links:
Layers?
Clean Code - Names
As for the ORM and DAO discussion, you might think yes, that the data access object is the same object used by the ORM to interact with the database, so they are not unique. Follow a more explanatory English OS link: DAO vs ORM(Hibernate) Pattern [closed]
Savero, welcome to the site. Your question is extremely complex, and I tell you, none of the answers found here will answer your question. To architect your project you need to know much more about the project. There is no rule of architecture. There are some common ones, but that doesn’t mean it will serve 100% for your project. Another thing, you confused ORM with DAO, DAO is a Pattern, ORM is a framework to mepar your classes with your database. Good luck
– Rod
Hi Rod, thanks! I know what ORM is. It’s that when having an ORM, you don’t have DAO, do you? What else do I need to inform?
– Severo
Severo, you can implement DAO with a ORM. DAO among its "specifications" implements abstract manufactures. Thus, for example, in a given context it may request that "entities" of different Orms be instantiated. Or, from implementations to specific formats, such as "entities" that manage a set of files serving XML database. Therefore, yes, you can implement DAO and use ORM together.
– Ademir Mazer Jr - Nuno