Solution design for ASP.NET MVC and Entity Framework database first

Question

I’ve inherited an ASP.NET (4.6.1) MVC solution that uses Entity Framework (database first) as its data access. All of the dbcontext calls and all of the business logic is in the controller methods. There are no domain models.... only view models and the generated entity models from EF.

So the solution structure is basically:

• Web (MVC web proj) → DAL (EF6...class lib proj)
• DAL contains
  • An .edmx
  • dbContext - auto generated
  • Entity models - auto generated
  • Partial classes for the entity models
  • Partial dbcontext (contains some custom logic)
• MVC
  • Controller
  • Private dbcontext at class level
  • Some simple to complex CRUD dbcontext calls in each method
  • Models
  • Only view models (some with dbcontext calls...oy)
• Views
  • Some views use VMs as their model while others use EF entity models

At the very least, I want to isolate my DAL from my presentation layer and clean up my controllers. I'm not trying to create the perfect app... but I want to make incremental improvements. So my goal this round is to create a logical structure.

So I’m adding another project in between Web and DAL (called Service or whatever) and I'm moving all of the dbcontext calls/logic into that layer. I'm adding another project (called Core) to hold some DTOs, custom exceptions, and other goodies.

So this is my current solution:

• Web (MVC web proj with Autofac)

  • Some service manager classes (injected into controllers)
  • This is where I get my DTOs and convert them into view models or convert view models into DTOs to send to the Service layer

• Core (not to be confused with .NET Core)

  • Referenced by all
  • Entity models (moved from DAL)
  • Partial classes for the entity models (moved from DAL)
  • DTOs, exceptions, etc...

• Service

  • Referenced by Web
  • Some service classes (injected into Web service managers) that will hold all of the complex CRUD dbcontext calls previously in controller methods (ex: var result = dbcontext.SomeTable where some id = n...blah blah)
  • I'll also inject the DAL dbcontext into these classes (which then requires a reference to Entity Framework)

• DAL

  • Referenced by Service
  • An .edmx
  • Dbcontext
  • Partial dbcontext (contains some custom logic)

So I'm keeping the auto generated dbcontext in the DAL, moving the generated entity objects to Core so Service can see them.

My questions:

1. Does it make sense to move all of the dbcontext calls/logic out of the controllers and into the Service? Some of the logic is simple but there are several controller methods that have complex business logic in them as well. I'm just not sure where to put this logic/calls to dbcontext.

2. Does the overall solution design seem OK or am I making it to complex? It's a medium size app but it has potential to grow and I want to set myself up for future development.

Thanks for reading...any input is appreciated!