When planning the architecture for a mid-large scale MVC web application how do you implement the layers to be as decoupled as possible and easy to test? (basically follow best practices) Let's say I'm using code first as my data access.
I struggle with what to define "business logic" as, and how it is meant to interact with the data layer. Taking a vehicle sales application as an example, would business logic be classes that performed tasks such as calculating the tax band for given vehicles, comparing mile per gallon statistics etc? As for the business entities (e.g. Cars, Vans, Motorcycles) I would put these in the data layer along with my
Also what would constitute application logic as opposed to business - I'm guessing things like session / user input validations?
So for example, a car controller might return an action/view result that lists the top ten cars filtered by type and best mpg. So let's say I have an
ICarRepository 'carRepo' injected into my controller(using the repository pattern / DI), I filter my cars from an action method parameter e.g.
var cars = carRepo.getCarsByType("hatchback");
So I've kept the data access knowledge out of my controller using a repository, now to keep the business logic out of the controller using a domain model - var result = new MpgCalculator(cars); - Let's say I need the calculator class because it needs to perform additional logic to calculate the best fuel efficiency, more than just loading / filtering entities from the DB. So now I have a data set for my view to render that used a repository to retrieve from the data access layer, and domain specific object to process and perform business related tasks on that data.
Am I making mistakes here? do we still need to use the repository pattern or can I just code against an interface to decouple the ORM and test? On this topic, as my concrete data access classe(s) dbcontext are in the data layer, should the interface definitions go into the domain/business layer meaning that if the data access technology is ever changed, my other layers aren't effected?
From what I have studied thus far my structure looks like this:
MVC Internet Application -> The standard internet project - models in here are ViewModels
Domain/Business layer -> business specific classes/models that controllers can use to process domain entities from the data layer before passing on to the relevant views
Repository abstraction necessary? -> I hear lots of debate on this, especially when using an ORM
Data layer -> Entity classes (Car, Van, Motorcycle), DbContext - Concrete data access technology layer