Principles of division of responsibilities in MVC architecture

I was recently responsible for a project that used the MVC framework of the Yii Framework. At first I thought the structure was very robust.

But as we deepened our understanding of business logic, we began to realize the seriousness of the problem.

I misunderstood the Controller in MVC, and took it for granted that based on past experience, all business logic was implemented in the Action of the Controller.

As a result, each Controller has thousands of lines of code, which is becoming more and more bloated.

Finally, I made up my mind to reconstruct the code. The origin was the need for an open API interface.

According to the current architecture, the code is basically impossible to reuse. I need to write many functions over and over again, which is really unacceptable.

Object-oriented programming is not just a term in textbooks!

Only when I started to practice did I realize how rare it is to have object-oriented awareness and a global perspective.

MVC design principles

1. What is the MVC

model- View-Controller (MVC) is a design framework (design pattern).

The goal of MVC is to separate business logic from user interface considerations.

This way, developers can more easily change each part without affecting the others.

In MVC, Model represents data and business rules; View contains user interface elements, such as text, forms, etc.; Controller manages the communication between models and views.

MVC is implemented in various programming languages. For example, in J2EE application development,

View may be implemented by jsp; Controller is a servlet, now generally implemented with Struts; Model is implemented by An entity bean to implement.

2. What problems did I encounter

Yii Framework is a popular PHP framework that draws on the ActiveRecord(AR) concept of Ruby on Rails.

Every table in the database can use the AR class to easily perform addition, deletion, modification and query operations.

It treats AR as a Model and recommends placing it under a directory called models.

So, after I automatically generated the AR corresponding to the table, I took it for granted that I already had the Model layer.

In fact, AR is just a DAO (data access layer), not a Model layer.

Almost all of our business is placed in the Controller: making various logical judgments on the forms submitted by users, performing calculations, instantiating AR to store data...

Because of a Controller There will be multiple actions, and each action has such business processing.

Finally, I found that my Controller code had exceeded 1000 lines.

Suddenly one day, the leader said that our system should open APIs for existing old systems to call and provide third-party interfaces.

The third party only needs to give a parameter, and the system only gives a result value. It does not care about the business processing.

The bad thing is that the Controller has already implemented those services, but it accepts form submissions. How can it also accept SOAP xml documents?

Controller, like condoms, should be as thin as possible.

Its responsibility should only be to accept user input and then immediately forward it to other classes for processing.

In this way, the Controller is only responsible for providing different interfaces, so that we can separate the business logic, and the separated business can be easily reused.

Who will handle this separated part of the business? The answer should be Model.

3. View’s responsibilities

The View part is relatively clear, it is responsible for display.

Everything that has nothing to do with the display interface should not appear in the view.

Therefore, complex judgment statements and complex calculation processes should generally not appear in View.

You can have simple loop statements and formatting statements. For example, the text list on the blog homepage is a kind of loop.

For PHP web applications, HTML is the main content in View.

View should never call the Model's write method.

In other words, View only reads data from Model but does not rewrite Model.

So we say that View and Model are inseparable.

Moreover, $_GET and $_POST are not directly accessed in View and should be passed to View by Controller.

In addition, View generally does not have any preparation for data processing, such as querying the database, etc.

These are usually placed in the Controller and passed to the view in the form of variables.

In other words, the data to be used in the view is a variable.

4. Model’s responsibilities

For Model, the most important thing is to save and output information.

For example, the Post class must have a title attribute used to save the title of the blog post, and must have a delete operation. These are all the contents of the Model.

Data, behavior, and methods are the main contents of Model.

In actual work, Model has the largest amount of code in MVC.

Model is the most complex part of the logic, because the business logic of the application must also be expressed here.

Pay attention to distinguishing Model from Controller.

Model handles business logic, and Controller simply coordinates the relationship between Model and View.

As long as it is related to business, it should be placed in the Model.

Data verification, public constants and variables should all be placed in the model layer.

That is to say, attributes or methods that may be reused should be placed in the model layer, once Definition, used everywhere.

Model should not access request, session and other environment data, these should be injected by the Controller.

Good design should be fat Model and thin Controller.

5. Responsibilities of Controller

For Controller, it mainly responds to user requests, decides what view to use, and what data needs to be prepared for display.

Therefore, the access code for the request should be placed in the Controller, such as $_GET, $_POST, etc.

Controller should be limited to obtaining user request data and should not perform any operations or preprocessing on the data. This should be placed inside the Model.

For data writing operations, the method of the Model class must be called to complete.

In response to user requests, view rendering is called.

In addition, generally there should be no HTML code and other presentation layer things. This should be the content of the View.

6. Enlightenment

The official documentation of Yii Framework has this paragraph:

In a well-designed MVC application, controllers are often very thin, containing probably only a few dozen lines of code; while models are very fat, containing most of the code responsible for representing and manipulating the data.

In short, Rich Model is Better.

The above is the detailed content of Principles of division of responsibilities in MVC architecture. For more information, please follow other related articles on the PHP Chinese website!