Question Is the MVC redundant?

[SQLDude]

I've been trying to decipher how the MVC design pattern works. I have found tutorials that state all of the business logic goes into the Model and others that state all of the business logic goes into the Controller and the data access goes into the Model. I have also come across tutorials that use multiple Repository classes for the data access and Controls to get data from the Repository and send it to the View with no Model classes involved. So I'm trying to understand if the Model and Controller classes are just redundant and while they could provide multiple layers for a complex application, they are not completely necessary for these simple tutorials. I think if I could understand the need for either the Controllers or the Models it would help. I understand the Views and I would probably just use Controllers and Repositories if I can get away with it.

 

[jmcilhinney]

Definitions and implementations are important and may vary. At its simplest, the model is just the data, the view is just what the user sees and the controller does everything in between. That's not really how it's done these days though. I learned the basics of ASP.NET MVC from Microsoft and I do it the way they showed, which is reasonable when using their MVC framework. Remember that MVC is just a pattern and there are various frameworks from various vendors providing various implements of that pattern and ASP.NET MVC is just one of those. For the large applications that we build in my office, this is how we structure things:

* Database - usually SQL Server
* Model project - contains Entity Framework context
* Repository interface project - contains interfaces for repository classes
* Repository project - contains one repository per EF entity and a UnitOfWork that wraps the EF context
* Repository IoC project - contains the Inversion of Control mapping for repositories
* Service interface project - contains interfaces for service classes
* Service project - contains one service per repository and includes all business possible logic
* Service IoC project - contains IoC mapping for services
* DTO project - contains data transfer object classes for moving data between service and presentation layers
* UI project - contains web site including controllers, views, view models (data shaped specifically for views)

The controllers contain the presentation logic and any business logic that can't be included in the service layer for some specific reason. It's worth noting that the service layer will often be hidden behind a web service and that's why it should include the business logic. That web service should be able to be access by applications other than the web site and still work, so putting business logic in controllers would go against that. For instance, we should be able to create a Windows app (WinForms, WPF, UWP) that can make calls to the web service without having to reimplement business logic.

In smaller applications, it may be fine to just put everything in the one project but, even then, I'd tend to create service classes to specifically contain the business logic and keep the controllers to just presentation logic.