Some comments before the reply:
- Entity Framework is already a ORM. You don’t need to create a project to envelope it;
- You do not need to separate the domain from the ORM layer. The correct is the context and the entities stay in the same project;
- You are putting an unnecessary level of complexity into your project. A Model is not a DTO because it is not anemic. In my view, you are incurring in the same mistakes of this question here;
- In
DataTransferObjects
(which, by good practices, should be discarded from its solution), the correct would be to group its entities by the namespace through a directory.
Let’s go to the answer:
It is necessary that each project referencing the EF has its own files app.config
and package.config
?
Yes, it is. I explain:
The app.config
indicates to the Entity Framework which data providers will be used. If there is a context in the layer, and the layer works independently of the Web project, configuration is required.
To prove this, try running a migration using your isolated domain layer as your initial project.
The package.config
indicates to Nuget what you are using as an external dependency on its Class Library. Each component of the solution has its own packages.config
. An example of this is that you will not use Web dependencies in a Class Library domain, and will not use EF in a web project that does not have any descriptive data access.
I know.. I found, some examples where authors separated domains from context. I went into . net a few weeks, I am not familiar with the best practices of organizing the project. This solution is a Desktop/WPF solution, but I intend to apply the MVC concepts. I had already noticed that the name
DataTransferObject
was not suitable.– Matheus Saraiva
I know these authors well. The intention is good, but it doesn’t work. There are a lot of answers here on the site that show that this is a bad idea. If it’s of interest to you, I can send you the links.
– Leonel Sanches da Silva
Yes, it will be useful.
– Matheus Saraiva
Here I explain why the practice of encapsulating EF in a repository is bad. Here I explain why a Model is not a DTO and what is the difference between them.
– Leonel Sanches da Silva