(A desktop application with a graphical interface, drawn by myself, a bit ugly)
Whenever humans struggle to develop a new desktop GUI program, at least the following types of work must be taken care of.
1. The layout of the interface (and of the elements in the interface).
It's a lot of work, and it has to be as beautiful as possible, or it won't sell.
2. There is some "logic" in the interface that needs to be handled
For example, in the salary calculation program shown above, the "Calculate" button is grayed out by default and cannot be clicked, but after the user enters pre-tax income, the "Calculate" button will be activated, indicating that the calculation has been made.
3. The so-called business logic.
After the user clicks on the "Calculate" button, he or she calculates the five insurance premiums, personal income tax and after-tax income.
The combination of these three makes for messy code, with slightly more complex programs running into thousands of lines, constantly challenging programmers to modify other people's code and add new features that are many times harder than writing them from scratch!
Everyone is floundering in the mud.
MVC for Desktop Applications
The program was getting more and more complex, the bugs were getting worse, and people had no choice but to beg the programming gods.
God says: If you want to get out of a rut, you must achieve Separation of concerns.
No one can understand it.
God explained, " There is a limit to what your human brain can process at the same time, so it's important to break down a large system into several relatively independent parts so that our brain can take control by focusing on one aspect at a time and ignoring the rest for a while. "
No one knows how to break it down.
God had to come up with a way to flesh out the theory of separation of concerns, and that way was MVC.
God tells mankind.
M stands for Model , which is dedicated to handling business logic and does nothing else.
For example in that salary calculation system. Calculate a person's salary, five-percent insurance, personal income tax, etc.
V stands for View, which focuses on page layout and data display.
For example, place the Button in a certain location, show the total revenue to a text box, and show the tax to another location.
C means Controller translates user input, manipulates the model and view.
For example, the user clicks a "Calculate" button in the interface, the View passes the request for the calculation to the Controller (obviously the View needs to know about the Controller, in other words, it needs to hold an instance of the Controller), and the Controller finds or creates a Model to execute the business logic: calculate the salary.
How should the results of the calculation be presented? The human asked.
God's chest: you can tell the Model to notify the View.
The Model needs to hold an instance of the View (which can of course be done through the Observer pattern) and call the corresponding method of the View.
For example: there may be a method onResult in View, let the Model call it, and pass a parameter object Salary in the call, won't it show the data?
Drawn as a flowchart it would look like this.
Everyone thinks MVC is a great idea and has started using it.
After time, humans find it irritating because in this MVC there are too many dependencies on.
View depends on Controller and Model
Controller depends on View and Model
The relationship between Model and View is weak, but some way to notify the View of data updates is needed.
Humans say, "They're still pretty tightly coupled to each other... dear God, can you change that? "
God, sensing that humans are still quite progressive, decides to continue to lend a hand: "Here's the deal, change the Controller to completely isolate the Model and View and let them change separately."
God changed the name of the Controller to Presenter and named the whole thing MVP.
In the MVP, the View only knows the Presenter, not the Model.
The calculation process is similar to MVC, the user clicks the "Calculate Salary" button, the View calls the Presenter, the Presenter operates the Model, and the Model does the business calculation. The key point is that the Presenter goes to update the View.
But the Presenter still needs to call the View's methods, which means that the Presenter has a dependency on the View, so the Presenter can't do unit testing alone, it has to wait until the interface is ready.
So God made another little improvement by having the View layer extract the interface, which the Presenter only relies on.
This way Presenter can be tested without relying on the real interface and also increases reusability, as long as the View implements that interface, Presenter can make a big difference.
After using the MVP for a while, the insatiable human felt uncomfortable again, because it was uncomfortable to have the Presenter call the View's methods to set up the interface, which still required a lot of annoying code.
A human whim: could we tell the View a data structure and then the View could automatically change with it based on that data structure?
God saw that mankind thought and showed appreciation.
He said, let me send you something called ViewModel, which can be bound to the View layer. The ViewModel changes, the View changes immediately.
Humans ask: ViewModel? What's in it?
God says: Take your payroll calculations, for example, ViewModel pretty much like this.
When the user clicks the "Calculate" button in the interface, you need to set a flag bit in the SalaryViewModel.
salaryViewModel.isCalculating = true;
This way a message can be automatically displayed to the user in the View: "Calculating ...."
When the salary calculation is complete, the grossSalary, netSalary, and tax properties in the SalaryViewModel will have values if there are no errors. At the same time, the corresponding content in the View will be updated, so you don't have to set it manually, is that convenient?
If there is an error in the calculation process, the errMsg of the SalaryViewModel will save the error message, and the error message will be automatically displayed in the View.
Humans say, "How can it be so smart? The ViewModel here doesn't seem to have anything to do with the View, does it? How the hell do I bind it?!!! "
God laughs: can you develop a framework? Wouldn't it be better to have the two tied together?
Humans have no choice but to take matters into their own hands.
(Note: In fact, Microsoft WPF and Silverlight, Android and other frameworks and systems can implement the mapping and binding between View and ViewModel)
MVC for Web Applications
Time flew by, man invented the Internet, Web applications sprang up, and B/S (browser-server) began to take off in a big way.
The user sends a GET,POST request through the browser, the server side processes it and generates HTML to the browser after processing.
Whatever the operation is, it is an access to the server-side URL.
Suddenly, mankind realized that the entire programming model had changed dramatically, and that the original MVC and MVP could not simply be applied.
If you compare the HTML page to the View of the original desktop application, the server cannot remotely process the View, whether it is a Controller or a Model.
Instead of asking God this time, mankind tried to improve on MVC on their own, and one of them, Rod Johnson, led a group of people to come up with a very successful SpringMVC.
Unlike MVC for desktop applications, the Model here can't send notifications to the View. And unlike the MVP, the Controller here doesn't call the View's methods to set up the interface either.
The Controller actually selects a View and then "drops" the model data to render it.
The original View becomes a View Template (e.g. JSP , Velocity, etc.), which is rendered and sent to the browser as HTML for display to the user.
Some call this MVC Web-based MVC to distinguish it from the previous MVC.
Separation of front and rear ends
In early human B/S applications, HTML was sent to the browser in its entirety every time the server side was accessed, known as a global refresh.
Then man invented AJAX, which can do partial refresh.
So browser-side applications became more and more complex, and then later humans went so far as to invent SPA (Single Page Application) on the Web, using an experience increasingly similar to the original desktop applications.
Humans have discovered that those MVC, MVVM and other patterns can be used on the browser side!
For example, using MVVM on the browser side, you can use MVC on the server side, and combining the two.