如果Entity Framework / DbContext是DAL / Repository，它在哪里适合3层架构？

Question

I've been reading articles on StackOverflow and other sites all day about best architecture practices and there are just so many conflicting ideas and opinions.

I've finally settled on an approach, but I am having a really hard time deciding where to place the EF objects (DbContext, Fluent APIs, Seeding data, etc). Here is what I currently have:

ASP.NET MVC Project : The actual web project. Contains the standard views, controllers and View Models (inside a Models folder).

Domain Model Project : Contains all POCO classes that define the database (domain) objects. Currently, does not mention or reference any EF objects.

Service Layer Project : Contains service objects for each type of domain object (eg, IProductService, IOrderService, etc). Each service references EF objects like DbSets and handles business rules - eg, add a Product, fetch a Product, append a Product to an Order, etc.

So the question is, in this configuration, where do EF classes go? Initially I thought in the Service Layer, but that doesn't seem to make sense. I then thought to put them in the Domain Model Layer, but then it ties the Domain Models to EF, which is essentially a DAL / Repository. Finally, I thought about creating a separate DAL Project just for EF, but it seems like a huge waste considering it will likely have 3-4 files in it (DbContext and a few other small files).

Can anyone provide any guidance?

Answer 1

There is no need for Domain Model since it will be redundancy. EF classes directly can act as Domain Model and they are converted to View Models while sending it to View. EF can be separated into different class library. Most of them use repository pattern along with any ORM incase it would be easy if they go for replacement. But I've seen criticism over using repository pattern, check this out.

Answer 2

Here is what I do:

Data:

• Has one class inheriting from DbContext.
  • It has all the db sets.
  • Overrides OnModelCreating.
  • Mapping primary keys and relationships.

Entities:

• Has every POCO classes.
  • Each property is decorated with needed data annotations.

Services:

• Each service has common methods (GetList(), Find(), Create(), etc.).

Business:

• Called from clients, orchestrate using services to perform a specific task UserChangePassword (this will check if this can be performed, then perform the task, or return error/unauthorized statuses among many others to make the client shows the correct information regarding the task. This on my case is where I log.

Clients (Desktop/Web/Wpf/etc).

I'm not saying this is the best approach, I'm just sharing what's been working for me.