"Original translation" understanding of MVC Design Pattern: The foundation of Open Web application (Basic article)

Original address: http://www.larryullman.com/2009/10/08/understanding-mvc/

Translation: SHADOWMYDX reprint Please specify

Recently, I planned to write a series about the YII framework that I used in the last few months (SHADOWMYDX: a Web development based on PHP5
Framework, details of Google's own) article. But before I start, I think we need to introduce the MVC design pattern First:
Model-View-controller. The MVC pattern (a bird before 30) has become the first choice for frameworks and many applications of all kinds. MVC model
The main focus is on the separation of application display and intrinsic logic, adhering to this principle, you may be able to not affect the application of the overall operation of the premise
Easier to modify or customize a section of your app.

Of course, the basic truth is quite easy to understand, but the actual implementation of MVC is rather difficult. In other words, when you really start
Before writing the code, it takes some time to master the pattern. In this article, I'm going to start with the various parts of the MVC pattern decomposition, speaking
How these parts are linked together. In subsequent articles, I will show how these parts communicate, as well as the $this
(This in shadowmydx:php) the pointer is exactly what it means in each section.

OK, let's get started. The MVC design pattern divides the application into three different parts:

• Model--Used to represent data
• View--Is the user interface (the user interacts with the data through this fishing batch)
• Controller-The action that the user can perform (SHADOWMYDX: Here is which is the actions)

I think the easiest part to understand is the model. This is a part of using and manipulating data. A classic representation of a model is the data
Library tables, in which case each instance of the model represents a row of data in a particular table. Note that if you have two relational tables, than
In the case of employees and departments, this would be represented as two different models, rather than one. You will find that the atomization of your model as much as possible is
A good choice. (SHADOWMYDX: The original is keep your models as atomic as possible, atomization can
It is important to understand that the model is used in order to manipulate variable data, as far as possible, not to combine complex data into one. Lift
example, if your site has a "Contact us" section, although users do not email you there is no data generated, but we
Still need a model to manage this piece of data, just in case. Models are not only used to represent data, but are also often used to manipulate
Data submitted by users who have been processed by the secure input program. (SHADOWMYDX: The original example is to eliminate user submissions
May be part of the malicious code in the data. ）

Views are also an easy-to-understand part of web development. The view contains HTML. Many of the frameworks I've used, such as Yii, Zend, and
Ruby on Rails uses a major layout page to arrange the rest of the page structure. The rest of the view pages represent all aspects of the
interface, such as the form area Ah, a list of records Ah, or a personal record. These different small pieces will be put into the main layout
Page to form a complete page output.

If you have a classic employee-departmental management app, you might have these view files:

• Main layout page for an employee page
• A form for adding & modifying employee data
• A list showing the employee list
• An area that displays all the information for a single employee

These files may also be reused by the departmental portion of the view, as long as the main layout page of the departmental section contains one of the entities in it.
to the.

Views do not only contain HTML, they must also have some parts of the PHP language (or other languages). This code should only be
Some very simple tasks, such as printing the value of a variable. One of the most common mistakes a beginner makes is to put too much business logic into
In the view. The goal of the view is to combine the data to produce a user interface, and the view should not "think" too much. Lift
Example, a view can use some conditional judgment to choose when to print a variable, or to use a looping statement to print a
Array, but the view should not do work such as formatting data or modifying data. If you have a user note displayed on the site
The original data comes from the database (in other words, part of the model) and uses it to calculate the final display in the view
On the results. So, the real calculation should happen in the model, not in the view (or in the controller).

The controller often plays a role in the binder between the view and the model, and of course it is not so obvious at times. (In fact, MVC sets
The boundaries of each part of the gauge pattern tend to be blurred easily. As I said before, a controller represents the action: some
And some of the actions performed by the view. Model actions include retrieving a single record from a database or getting all records, depending on
The diagram action responds to user events: Submit a form, load a page, and so on.

When these parts are combined through a controller, the user accesses a similar www.example.com/index.php/employee/list
page, it causes a "list" action in the employee controller. This list action may call the "Retrieve all" move
Saulay gets all the data from the model. The controller then sends the data to the "list" view, which will use the
A loop prints out all the employees.

I will show you some real-world code in future articles, please look forward to

(End of text)

"Original translation" understanding of MVC Design Pattern: The foundation of Open Web application (Basic article)