I'm starting a new Enterprise application for the first time in a while, so I want to make sure I get the architecture correct right from the get go. I plan to use MVC and EF (not Core for either, at this time), as well as Unity for Dependency Injection. This application will be an extension of sort to an already existing 3rd party app + database. EF will be database-first.
Most of this is fairly new to me, so hopefully I get all the terminology correct.
I've been reading countless articles on how to properly organize everything, but a lot seems to be somewhat contradictory. Some common themes are
- Do not use the Repository Pattern with EF, since EF is already basically a repo
- Separate app into layers
- Data Layer (dbContext, EF POCOs)
- Business Layer (business logic)
- Service Layer (mapper between business and presentation)
- Presentation Layer (thin controllers)
My current plan is to have two separate projects
MyApp.Business which contains
- all EF generated objects (DbContext and entity partial classes)
- extra partial classes to add functionality
- business logic classes
- injecting connection string information into "MyDBContext"
MyApp.Web which contains
- all MVC classes (views, controllers, view models, etc)
- Service classes that call business logic, and transform between BL/EF models and view models
- injecting "MyDBContext" and business layer classes into the services
- injecting the services into the controllers
Is this the right way to design this?
The business logic seems too coupled to EF. How do I de-couple this without essentially creating a repository? Do you just assume you won't switch to NHibernate or even a non-ORM DAL?
How do I set up the dbContext in a way that lets me test business logic with mock data? Examples I've seen all over have the system injecting "MyDBContext" type objects, and not interfaces.
I combined the DAL and Business Layer so that I can make use of partial classes with the models. That ok?