This is the output of what I learned from researching MVC. If you have any suggestions, I would appreciate it if you could comment.

Here, we mainly deal with MVC, which is premised on a Web system with a DB.

Who is the target of this article

・ People who are new to the word MVC and want to know what it is ・ People who want to know how beginners perceive MVC

What is MVC?

In a nutshell, it's ** one of the models for organizing programs **. Based on the idea that "a system that can be visually operated by the user can be divided into parts called ** Model **, ** View **, and ** Controller **," these are abbreviated as MVC.

What kind of unity are "M", "V", and "C"?

For example, consider the Amazon product purchase page that everyone has used. This is the flow of processing when you press the purchase button on the Amazon product page. (I don't know the internal implementation, so I'll assume it's implemented based on MVC)

Overall picture

The whole picture looks like this.

The flow is as follows (please point out any inappropriate points).

① Show the product page

Show the product page to the user through the monitor.

The user who sees the product page confirms the position of the purchase button.

② Press the purchase button

The user hovers the mouse cursor over the buy button and clicks.

③ Notification that the purchase button was pressed

Sends a notification to the Controller that the purchase button has been pressed. Triggers the system to start processing.

④ Request processing associated with pressing the purchase button

Upon receiving the notification, the Controller requests the Model to "take appropriate action because the purchase button has been pressed".

⑤ DB processing

The Model that received the request processes the DB according to the request contents. In this case, it is linked to the action of "user purchasing the product", so ・ Reduce the inventory of target products by 1. ・ Acquire information on target products And so on.

⑥ Request to draw purchase page

Ask View to "display the purchase page".

⑦ Reference of product data

View goes to Model to get the information needed to draw the purchase completion page. Since the DB processing is completed at the stage of ⑤, the Model has the information necessary to draw the next page.

⑧ Completion of drawing the purchase page

Based on the acquired data, View draws the purchase completion page.

The flow is like ... Now that you have a rough idea of what each Model View Controller is doing, let's sort it out in words.

What is View? **

It's hard to understand from Model, so let's start with View. View is the most intuitive and easy to understand.

In a nutshell, View ** draws the part that is visible to the user. In this case, ** processing to display the purchase completion page ** is performed.

This is the screen after adding a book with a design pattern to the shopping cart. View is displaying this.

View's job is to ** connect the system to the user **. Thanks to View, information such as "how much you move the mouse and click to purchase the product" and "the purchase of the product named XX has been completed" is transmitted to the user.

Since product information is required, ** Model ** is doing it by connecting to the DB and fetching product information. View is just a display. I will explain later in "Points that are easy to make mistakes".

What is Controller? **

Next is Controller. ** Controller ** receives input from the user and issues commands to Model and View. It's like a commander.

In this case, ** it receives the user's action of "pressing the purchase button" and converts it into an instruction that can be processed by Model and View **.

For Model, "Please reduce the inventory of the target product" "Get the information of the target product"

Each view has an instruction to "draw the screen after adding it to the shopping cart".

What is Model? **

When I looked it up,

Model deals with the entire business logic.

It is very often explained that.

However, when we investigate the word "business logic", we finally find that ** "there is no clear definition" **.

In other words, the meaning depends on the context.

Personally, the explanation of the model that fits best is ** "Model is doing all the work except View and Controller" ** That is.

The process of acquiring data from the DB and the process of processing the data for display in View are all done by Model.

here ・ Access the DB and reduce the inventory of products by one ・ Get information about products in your shopping cart We are doing the processing.

What is the reason for dividing into MVC?

So far, we have explained each part of MVC. So why do we need to do this? There are two main reasons.

1. Easy division of labor

Suppose that the development team has "an engineer who is good at creating processing around DB" and "an engineer who is good at thinking about UI".

At this time, if the source of the system is separated by MVC, the former should develop "Model" and the latter should develop "View".

There is an advantage that each person in charge is clarified and work efficiency is improved.

In this way, it is very important that each part of the system is clearly organized when developing as a team.

2. Easy to maintain

There is no such thing as "then, does it make sense to separate MVC in personal development?"

When you organize your system with MVC, each function becomes independent.

In other words, ** When one part is changed in function, the influence on other parts is reduced. ** **

For example, changing the position of the shopping cart button does not mean changing the processing of the DB associated with the shopping cart button.

If you have written the DB processing in View, you may need to change it (the system I made in the past is like this).

Easy to make mistakes

Write the process to be written in Model in View

This is a mistake I made when I first developed the system from scratch. I wrote in View the process of connecting to the DB and the process of processing the data.

Since it is a small system, I made it with the idea that "it's OK if it works", but with this idea, a program with extremely low maintainability can be created.

Summary / impression

・ MVC is a program organization model

Model A model for organizing programs in View Controller. The main purpose is to make it easier to divide labor and improve maintainability.

・ I think it's easier to understand if you say "VCM"

Considering the flow in which the user looks at the View, operates the Controller, and the Model processes it behind the scenes, I thought it would be easier to intuitively say "VCM". Is there any reason for the order of MVC?

References

https://hijiriworld.com/web/mvc-concept/ MVC understood by cartoon https://www.slideshare.net/MugeSo/mvc-14469802 After all your MVC is wrong https://qiita.com/s_emoto/items/975cc38a3e0de462966a About MVC model https://ja.wikipedia.org/wiki/%E3%83%93%E3%82%B8%E3%83%8D%E3%82%B9%E3%83%AD%E3%82%B8%E3%83%83%E3%82%AF "Business Logic" Wikipedia http://at-grandpa.hatenablog.jp/entry/2013/11/01/072636 Think again about "MVC misunderstanding"

[MVC model] A memo that a beginner learned MVC