MVC: view and model interaction regarding data access, etc.

Question

Should the model be data structures? Where are the services (data access, business logic) in MVC?

Suppose I have a view that shows a list of customer orders. I have a controller class that handles clicks on view controls (buttons, etc.).

Should the controller run a data access code? Think, click the button, reload the order request. Or should it go through the model layer at all?

Any code sample would be great!

Answer 1

I usually implement MVC as follows:

View - receives data from the controller and generates an output signal. Usually only display logic should be displayed here. For example, if you want to take an existing site and create a version for mobile / iPhone, you must do this by simply replacing the views (provided that you need the same functionality).

Model - wrap access to data in models. In my applications, all of SQL lives at the model level; direct data access is not allowed in views or controllers. As Eli points out in another answer, the idea is to (at least partially) isolate your controllers / views from changes in the database structure. Models are also a good place to implement logic such as updating the “last modified” date whenever a field changes. If the main data source for your application is an external web service, consider whether this is being ported to the model class.

Controllers - Used to glue models and views together. Implementing application logic here, validating forms, transferring data from models to views, etc.

For example, in my applications, when a page is requested, the controller will extract all the data from the models and transfer it to the view to create the page that the user sees. If this page was a form, the form can be submitted, the controller processes the validation, creates the necessary model and uses it to save the data.

If you follow this method, the models will become quite versatile and reusable. Your controllers have a manageable size and complexity, since access to data and their display have been removed respectively in Models and Views, and your views should be simple enough so that the developer (with a little preparation) can understand them.

Answer 2

I would not put the Data Control Code in the controller.

To build on what has already been said, it is important to think about layering in layers. For example, you will likely have several levels inside the model itself - a data access level that performs any access to ORM and the database and a more abstract level that represents business objects (without any knowledge of HOW to get access to their data).

This will make it easier for you to test the components of your system as it supports mockery.

Answer 3

I like to save “contracts” or interfaces for saving a model or accessing a service at the domain (model) level. I put data access implementations or service calls at a different level.

Controllers are created using constructors that accept interfaces for services, for example. ISomeService as parameters. The controller itself does not know how service levels are implemented, but they can access them. Then I can easily replace SqlSomeService or InMemorySomeService.

I was also pleased with the specific implementation of the service, which takes the domain (model) level repository as a parameter of its constructor. For example: ICatalogRepository with SqlServerCatalogRepositry: ICatalogRepository is passed to the CatalogService (ICatalogRepository, ISomeOtherDependency).

This kind of separation is easier with dependency injection frameworks.

Answer 4

The view will show what should happen when you click on the user interface at the management level, which will contain ALL the business logic, and in turn will invoke a model layer that will only make database calls. Only the model layer should make database calls, or you will defeat the goal of the MVC design pattern.

Think of it this way. Let's say you change your database. You would like to limit the number of code changes needed and keep all these changes together without affecting other parts of your application. Thus, while maintaining access to data at the model level, even simple calls, you limit any changes necessary for the model layer. If for some reason you had to get around the model layer, now you will have to expand any changes necessary for any code that knows about the database, making such maintenance more complicated than it should be.