Entity Framework, you doubt the solution structure (app.config and package.config)

Question

I started a solution with Entity Framework code-first. In the solution structure, I separated the domains from the other EF files (context, etc.). That is, the domains were in a separate project. However, for me to be able to make use of EF data annotations, I needed to reference EF in the domain design as well. This way, I have the EF referenced in two places, in the project of the domains and in the project where the other EF files are, so I end up having two files app.config and two package.config. It is necessary that each project referencing the EF has its own files app.confg and package.config?

Answer 1

Some comments before the reply:

1. Entity Framework is already a ORM. You don’t need to create a project to envelope it;
2. 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;
3. 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;
4. 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.