preface

The MV(X) series of architectural patterns have been discussed from the original MVC to the current MVVM (VIPER architectural patterns are not discussed). Different people have different views on architectural patterns, and there are many blogs about architectural patterns. From the contact with MVC to the actual application, there are always many questions, and I was also asked the wrong questions in the interview. The interviewer’s words deeply touched my soul, and I thought over the pain, so I took the time to deeply understand this knowledge. Now I have my own views on the architecture mode of MV(X) series. Writing this blog is not only to express my views, but also a summary. In addition, the article is more from the perspective of iOS development to think.

The traditional MVC

The MVC pattern, first proposed by Trygve Reenskaug in 1978, is a software architecture invented by Xerox PARC in 1980s for Smalltalk, a programming language. The PURPOSE of the MVC pattern is to achieve a dynamic programming that simplifies subsequent modification and extension of the program and makes it possible to reuse certain parts of the program. — Wikipedia

The MVC pattern classifies the objects in the program according to their responsibilities or functions, and divides them into three basic parts: Model, View, and Controller. MVC is a composite pattern composed of several basic design patterns. That’s why MVC is called a design pattern. In addition to the classification of the objects in the program, it also specifies how they communicate.

V: Responsible for UI display and event interaction processing

M: Data storage and data processing

C: Communicates with V and M and manages the life cycle of V and M.

Take a look at the traditional MVC architecture diagram (citing Apple’s diagram) :

When the View receives a user event, the event processing is handed over to the Controller. After receiving the event, the Controller can request a data change from the Model or request the View to change its behavior or appearance. When Model’s data changes, Model notifies all registered observers, and the View updates its appearance when it receives notification of the change.

In this mode, the Controller is a policy of the View and is responsible for the View’s event handling and notifying the Model of updated data. Different View events are different, and different Model data update interfaces are also different. In this case, Controller is difficult to reuse. The only reusable modules are View and Model. However, you can see from the figure above that there is coupling between the View and Model, and the View and Model are not completely isolated. View updates depend on Model. For reuse purposes, View updates should not depend on Model, but should be independent of Controller and Model, and similarly, Model updates should be independent of Controller and View. Let’s take a look at apple’s ideal MVC pattern.

Apple’s ideal MVC

Apple’s ideal MVC is to completely separate the View from the Model. There is no coupling between the View and the Model. The View and the Model communicate with each other through the Controller. Here the Controller is an implementation of the mediator pattern. View is also the implementation of command mode. Through target-action mechanism, View can be used as the executor of the command, corresponding to Target. Action is a command. The response chain is the dispatcher, responsible for issuing orders to the appropriate executor.

Apple’s ideal MVC architecture diagram:

In the iOS MVC

In iOS, we know that there is a UIViewController class, and ViewController came about because Apple tied the View and Controller together to improve development efficiency. From the actual use can feel the development efficiency has been improved. It’s also easy for beginners to get started quickly, because there are no architectural patterns to consider and no strict distinction of responsibilities between different objects. Most beginners are still used to a hodgepodge of programming, leading to the emergence of Massive Controller. The ViewController does a very complicated thing, is responsible for the life cycle of the View and the Model, responsible for the communication between the View and the Model. Responsible for page jump, responsible for network request, responsible for data processing, etc. This violates the principle of uniformity in design patterns. Projects become difficult to maintain as business increases.

MVC architecture diagram in iOS:

Even with apple’s design, we can still implement Apple’s ideal MVC. We need to slim down the ViewController. View’s responsibilities remain the same. The business logic is separated from the Model, and the ViewController is responsible for the life cycle of the View and Model, the communication between the View and Model, and the page jump. The View delegates event handling to the ViewController and provides an interface to update the UI. ViewController, Model handles initiating network requests, notifies the ViewController when the data is processed. And then the ViewController is updating the View. This keeps the View and Model separate, making it easy to reuse and test, while reducing the burden on the ViewController. When the number of services increases, you can add multiple MVC to divide services, avoiding the need to write all business codes in the same MVC code.

MVC summary

MVC design is put forward in order to achieve a dynamic programming, make the follow-up of process modification and extension of simplification, and made it possible to reuse of one part of the program, MVC is conducive to the further development of application in the long run, extensibility, maintainability and testability has become easy, because of the characteristics of the MVC MVC application object for the division, View and Model can be reused.

However, the disadvantages of MVC are also obvious. In traditional MVC, only Model can be reused. Update of View depends on Model, and View is not independent of Model and Controller. Controller, as the communication channel between View and Model, processes the events submitted by View and notifies Model of data update, etc. Too much customization of Controller itself makes it difficult to reuse. From a testing standpoint, it’s hard to test the business logic in the Controller. In terms of Apple’s ideal MVC, in this mode, Controller cannot be reused, and View and Model have high reusability. The test View and Model provide external interfaces through which you can judge whether the logic and interface updates are correct. At the same time the Controller needs to manually implement the View’s updated code and various event broker communication methods.

MVP

Passive View

In a concrete implementation, the Presenter holds a weak reference to the View and is not responsible for managing the View lifecycle. When the Model notifies the Presenter of data changes, the Presenter can update the View. For structural purposes, presenters are not dependent on the View. They usually use a custom View protocol that abstracts the method of updating the View from the business interface. Then presenters hold a reference to this protocol and are not dependent on the View. This is consistent with the dependency inversion principle of design patterns. At the same time, the Presenter’s behavior protocol can be abstracted from the business, and different Presenter implementations can be switched. Here, View is a policy, Presenter is a policy, and it’s a policy design pattern.

Supervising Controller

MVP summary

The decision to use Passive View or Supervising Controller depends largely on how testability you want your application to be. For high testability, Passive View is best, and all UI logic can be tested with a test Presenter. To reduce the need to write UI updates in Presenter, select SuperVising if you want code to be concise and not fully testable.

MVVM

MVVM is a variation of Martin Fowler’s PM (Presentation Model) architectural pattern. Both MVVM and PM come from the MVC pattern. MVVM was developed by Microsoft architects Ken Cooper and Ted Peters by leveraging WPF (Microsoft). NET graphics system) and Silverlight (an Internet application derivative of WPF) to simplify event-driven programming for user interfaces. MVVM is also known as Model-View-Binder.

Presentation Model

The PM pattern is similar to MVP in that it separates behavior and state from the view layer. PM abstracts the view (creating the view model) in a way that is independent of a particular user interface platform, and MVVM abstracts the state and behavior of the view in the same way. Abstracting a view is the same as defining a view model in a protocol we mentioned above. Unlike Presenter, PM mode puts all the state and behavior in a view into a single presentation Model (PM), coordinating the Model and providing an interface to the view layer. In other words, BY introducing the presentation model, PM encapsulates data and complex business logic in the model layer into attributes and exposes simple data to the view at the same time, so that the attributes in the view and the presentation model can be synchronized.

The MVVM with WPF

The MVVM summary

The MVVM mode uses Binder layer to bind the View and VM in both directions, reducing the need to manually update the View code and separating the View from the Model. The Binder layer implementation in iOS can be implemented via RAC. At the same time, MVVM has drawbacks. MVVM’s creators say that the overhead of implementing MVVM is “excessive” for simple UI operations, and data binding in very large applications can lead to considerable memory consumption.

conclusion

From MVC to MVVM, MV(X) series of architectural patterns are essentially evolved from MVC, which differentiates the responsibilities of program objects, reduces the coupling between View and Model and improves their reusability, and can be further optimized for testability. The choice of different architectural modes depends on the mode suitable for the development platform. Apple recommends MVC, Android MVP, and MVVM for the front end. Of course, you can choose a more suitable design pattern according to the requirements of the project. No matter what architectural patterns you choose, I think it’s important to understand them in order to write better projects.

Refer to the article

Model-View-Controller

MVC

Brief introduction to MVC, MVP and MVVM architecture patterns

In-depth understanding of MVC

In-depth analysis of MVC, MVP, MVVM, VIPER

What are MVP-Passive View and MVP-Supervising controller

Design patterns