Printable View
What code should be in the controller? Should most code be in the model and you just call the methods (from the model) in the controller? Or should the model only contain the class with properties, but shouldn't contain so much methods? I'm a bit confused with this.
The model is the data. It should basically be dumb. As the name suggests, the controller should be in control.Quote:
Originally Posted by benmartin101
That said, many people separate layers out even further. In my office, we have a general template for MVC web sites that includes multiple projects:
Domain: EF data context
Data: one repository class per EF entity, which is responsible for moving instances of that entity between the EF context and higher layers
Data.Interface: one interface per repository class
Dto: one data transfer object class per EF entity and logic to map data between DTOs and corresponding entities
Service: one service class per EF entity, which is responsible for business logic relating to that entity, moving data between repositories and higher layers and mapping between entities and DTOs
Service.Interface: one interface per service class
Wcf: one WCF service per service class
Web: ASP.NET MVC project with one controller per EF entity, which is responsible for presentation logic relating to that entity
If you're not going to stretch things out like that then the service and repository logic should be pushed up into the controller. Something like an EF context might also be in the same project as the controllers.
Hmmm, I think I'd disagree with JM there but it is a bit woolly.
As I've always understood it the model isn't the data, it's the business model where all the business intelligence and data resides. The controllers are really just an abstraction layer to separate the UI from the model. That was always my understanding of the MVC pattern rather than Microsoft's specific implementation of it.
That said, EF seriously muddied those waters because it creates a set of "dumb" classes which map to the database entities. This creates a great temptation to code your business logic into the controllers which, in turn, starts creating the opinion that the model is the data.
I always felt, though, that the EF classes really represent an abstraction layer between the business logic layer and the data layer. But I always felt the Model in MVC was basically a combination of the DAL and BLL. The MVC pattern is meant to separate the UI from the BLL, not the BLL from the DAL.
I'm curious to se what other's think on this so I think I'll have a quick google...
edit> This link says I'm right
This link has a divided opionion
and I'm willing to bet that if I searched further I'd find at least one link that said I was wrong.
Which probably means there is no strictly right or wrong answer. I'd suggest just having a bit of a google, reading the opinions and arguments and then just make a choice that works for you.