I have an MVC site which uses the repository pattern. I don't feel like I'm using the MVC style enough, so I'm getting ready to re-architect some of it. But I'm also wanting to do it so if the front-end ever changes, it will be easier to swap out.
Here's what I have currently
Models - some of my models contain my entities/classes directly. (Login model contains Customer class, which is a direct correlation to the Customer table/repository class) Views - some of my views contain repo queries - ie
_customerRepo.Query().FirstOrDefault(c => c.Login == User.Identity.Name);
Controllers - Not as big of a deal here, controllers calling some repo queries, and some of them also use some services to call the repos - ie
Here are my thoughts:
1) Models should contain ONLY the data needed to be presented on the view. Even if all properties of the Customer table/object are presented on the view, they should be re-written to their own model/class so the view knows nothing about the database architecture or backend objects
2) Views should only be accessing model objects
3) (And this is where I'm struggling on which path to take)
a) Controllers (or somewhere on the MVC side, should be code that converts the object data returned from the repo/services and converts them to the models. I'm assuming I could just place this code in a model constructor. But I've noticed that DI expects a default empty constructor in case there are validation errors
b) Controllers call repo interfaces on well-named methods to retrieve data (ie _customerRepo.GetAllCustomers()
c) Controllers ONLY access a service layer. The service layer then is the only thing that interacts with the repo layer.
Am I trying to extract the model, controller, service, repo layers too much? Is the serivces layer too much overhead since it can all be done by the repos?
What's the recommended approach to converting the objects/business entities to the models?