5

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 (e.g., IProductService, IOrderService, etc). Each service references EF objects like DbSets and handles business rules - e.g., 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?

Amberite
  • 1,379
  • 3
  • 14
  • 27
  • What is driving you to create three projects, instead of just one? – Ed Chapel Jun 01 '13 at 08:23
  • Better extensibility. With a separate project for domain models and one for services, you can have another application (for example, a WinForms app) that can easily consume the domain and business logic without having to duplicate the code. Also, if there is a WinForms app and an MVC app, things like business rule changes only need to be made in one place instead of two. – Amberite Jun 01 '13 at 16:38

2 Answers2

3

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.

Sunny
  • 4,765
  • 5
  • 37
  • 72
  • I'm using EF Code First, so I'm creating the POCO classes myself. However, I was under the impression that my Domain Model should be purely POCO classes, and that EF DbContext et al should live elsewhere. Is this wrong? – Amberite Jun 01 '13 at 05:56
  • Like Sunny referred to--take your POCO classes and create a new project within your solution that just contains your POCO classes (not your DbContext) .. that assembly can be very light and doesn't need to have any dependency on EF .. your DbContext will go in your WPF/WinForm/WebForm/MVC/Silverlight/Whatever-assembly which will depend on EF. That's the best approach and the one you typically see Microsoft demonstrate when showing EF Code first. – Derek Curtis Jun 01 '13 at 06:18
  • @DerekCurtis: The problem is that if I put the DbContext in the MVC project, then the Service Layer needs to reference the MVC project, and the MVC project also needs to reference the Service Layer. Seems like a circular reference? – Amberite Jun 01 '13 at 06:23
  • If you'd like to use service layer, then dbcontext related code will be in services. DAL will contain EF, IUow, etc. POCO can be present in different library or DAL layer under different namespace. Reference it in service and MVC application. But service layer is like repository pattern that is not required, you can directly use EF here without any problems with unit testing. Check http://weblogs.asp.net/scottgu/archive/2010/07/16/code-first-development-with-entity-framework-4.aspx – Sunny Jun 01 '13 at 06:43
  • @Sunny: So if I understand correctly, you're saying to have MVC project, POCO project, and that's it? You're saying the service layer is not necessary, but isn't it bad form to have MVC Controllers have direct access to EF and perform direct queries? That's why I was thinking of having the Service Layer project so that the Controllers can reference IServices which would handle EF queries and business rules. Thoughts? – Amberite Jun 01 '13 at 16:49
3

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.

Esteban
  • 3,108
  • 3
  • 32
  • 51