Interface-oriented programming (III)-Model Research

Through the previous two articles, I think you have some understanding of the Idea of "interface-oriented programming", and have gained a certain intuitive impression through the example in the second article. However, the example in the second article aims to demonstrate the implementation methods for interface-oriented programming, which is relatively simple and cannot reflect the advantages of forward-to-Interface Programming and the connotation of this idea. As the final part of this series, this article analyzes several in-depth models or architectures and hides the interface-oriented ideas behind it. In this article, I will analyze the MVC mode and the hierarchical architecture of the. NET platform.
This article may be abstract and understandable.

1. Start with MVC
Introduction to MVC:
This article does not intend to explain the MVC Architecture in detail, but focuses on the Interface-oriented ideology. So here, we will only give a brief introduction to MVC.
MVC is a composite design mode for presentation layer design. M, V, and C represent model, view, and controller respectively ). Their responsibilities are as follows:
Model: used to store data in an application and its running logic. It is the application entity.
View: Responsible for the visible part, used to interact with users and present data. The view is only responsible for display, not for interpreting user operations to the model.
Controller: responsible for interpreting user behavior to the model. Call the model logic based on the specified policies and user operations.

I have drawn a picture of the relationship between the three elements. For details, refer:

There are several types of interactions between them:
1. When you perform any operations on the view that require model calling, the request is intercepted by the Controller.
2. The controller translates user behavior into model operations according to its own policies and calls the corresponding logic Implementation of the model.
3. The Controller may specify some changes to the view when it is connected to the view operation.
4. When the model status changes, the view will be notified in some way.
5. The view can get the status from the model to change its display.

After the introduction of MVC, someone may ask, what is our topic? What about interface-oriented ideas? In fact, interfaces are everywhere in MVC. Next, I will explain several of them.
1. First, we can see that views and models interact directly, that is, the four and five points above. But one thing may surprise you: neither of them knows anyone, that is, they do not know what the other person is doing, what attributes they have, and how they are used, but they can interact. How is this done? Because each of them knows that the other party has implemented a certain interface.
This is a major role of interface-oriented thinking: interaction between classes that do not know each other. This is very beneficial. First, the coupling degree between them is greatly reduced. Secondly, both parties can replace it. As long as the same interface is implemented, there is no problem.
Make an inappropriate analogy. We all know that the phone number 120 is an emergency phone number. In fact, 120 is an interface, because when you call this phone, you do not know which hospital is there, or even whether it is a hospital. You only know that the place at the end of the phone can save lives, you can also say that the Ihelp interface is implemented. In this way, you can use a number to connect with all rescue agencies. In an emergency, the wiring control team will send your request to the nearest available organization, you can get help as quickly as possible.
Now let's assume that we didn't use the interface-oriented idea to see what would happen: first, my 120 number is bound to the First People's Hospital in this city, that is, when I dial 120, only the first people's hospital can be called. If one day my food was poisoned, I quickly dialed 120, but the phone told me that all the ambulances in their hospital had been dispatched. I asked how to connect the phone number from another hospital, MM gently told me over there, asking me to call Netcom and re-wiring for me. So I vomited blood and died ......
Let's get down to the truth. Here, I want to introduce a design pattern called the observer pattern. This pattern is like this: there are two types of entities in the entire pattern: the observer and the observer, which implement an interface respectively. Here we call it iobserver and iobserversubject. Iobserver has only one method, such as update. When the status of the observer changes, this method is called to notify the observer. The iobserversubject interface has two methods for the observer to call. One is used to register the observer to the observed object to be observed, and the other is used to remove the observer.
Generally, one observer corresponds to multiple observers.
In MVC, the view is the observer and the model is the observer. When the model state changes, the update method of all observers is called to notify the view model to change. The view writes a response in the update method.Code To complete the operation. By using this method, views and models can interact with each other only when they depend on interfaces, without strong coupling. In addition, the views can be replaced without changing the model. (As long as iobserver is implemented)

2. Another interface used in MVC is the controller. Here I want to introduce a design pattern: strategy ). In MVC, the controller uses this mode.
As I said just now, a view is responsible for interacting with users. However, it is only responsible for the interface display. How should the system respond when a user performs an operation (such as clicking a button, the view is not responsible. It only submits this action to the controller. The controller translates user operations into model logic based on the built-in policies. This means that the model can respond differently to the same view and operation, depending on the built-in policies of the controller. Therefore, our system can have many controllers with different policies. When the view wants to change the policy, it can change the controller. How can this problem be achieved? In this case, the view cannot be coupled with a specific controller, but depends on only one Controller Interface (such as icontroller) and aggregates an icontroller instance. When you want to change the policy, you can change the Controller dynamically when the system is running. This is the implementation of the Policy mode.

The MVC interface idea will be introduced here first. In fact, interface-oriented interfaces are still used in many aspects of MVC. Because this article does not specifically introduce MVC or design patterns, it does not explain the patterns used, but focuses on the Interface-oriented ideology. If there is no basis for the design model, reading the above may be difficult. I hope you will forgive me! I plan to writeArticleTo parse MVC.

2 .. the interface-oriented idea of the layered architecture under the. NET platform
we know that, in larger system applications (especially the B/S architecture ), A better method is layered architecture. The so-called layered architecture refers to dividing the system into several layers from responsibility, each layer performs its duties, and the upper layer relies on the lower layer to complete the operation.
On the. NET platform, the classic layered architecture is a three-tier architecture, with data access layer, business logic layer, and presentation layer in sequence. Responsibilities:
data access layer: Responsible for interacting with data sources and completing data access and other operations.
business logic layer: completes logical operations related to system businesses.
presentation layer: responsible for all operations related to system representations such as user interaction and data presentation.

as we said just now, the layered architecture is down-dependent (without dependency inversion), that is, the business logic layer needs to call the data access layer to complete data source-related operations, the presentation layer calls the business logic layer to complete the business logic work. However, the presentation layer does not depend on the data access layer.
In this architecture, each layer is not a class, but a class family. For example, in a CMS system, the data access layer may have a series of classes, the data access operations of users, articles, comments, and other business entities are respectively responsible, and the business logic layer is the same. If we directly rely on the business logic layer to instantiate the class of the data access layer, and the presentation layer to instantiate the class of the business logic layer, it will cause strong coupling. If I want to change the database from sqlserver to MySQL, I need to change the entire business logic layer code. This is a bad design. (Do you still remember the "open-close" principle?) so the general practice is to define interfaces for the data access layer and business logic layer, the business logic layer does not depend on the specific data access layer, but only depends on the Interface family of the data access layer. The presentation layer also depends on the Interface family of the business logic layer. In this way, when changing the database, we do not have to rewrite the entire business logic layer, because the business logic layer does not have any specific classes in the data access layer, but is implemented through interfaces. In. net, as long as the configuration file and reflection mechanism are used together, and then the abstract factory design pattern can be used to achieve "dependency injection ", that is, select the corresponding level component based on the configuration without modifying the code. In this way, we can implement the data access layer separately for the database, or write the data access layer of the Orm, or even based on XML, as long as the interface family of the data access layer is implemented, it can be seamlessly connected to the business logic layer, greatly improving the flexibility and maintainability of the software. Of course, the same is true for changing the business logic layer.
if we talk about interfaces from a micro perspective, this example shows the connotation and advantages of interface-oriented programming from a macro perspective. Sorry, I cannot explain this architecture in depth here. If you are interested, please refer to Microsoft's official example. Net petshop4. (However, in this example, the business logic layer does not define an interface family, but is strongly coupled with the presentation layer. This may be because the business logic in this system is not changed. In addition, because it is an example and not a real B2C system, the business logic layer is very simple .)

Well, this article is here. I hope you will have some understanding of "interface-oriented programming" through these three articles. Of course, I am only playing a role to inspire others. The true meaning and essence of it also require you to gradually understand it from practice. In addition, the idea of interface-oriented is not isolated. It is the essence of object-oriented big series and is mutually infiltrated and interconnected with each other. In fact, many design patterns are the embodiment of interface-oriented ideas. We should put these together for learning, so as to truly provide our own Object-oriented Thinking and practical ability.