Talk about the view layer schema

Objective

I've been thinking about some of the iOS view architectures lately, so I've started to tangle with MVC, MVVM and other architectures. Because the original code in the project is chaotic, the accumulation of accumulated, maintenance of the people also changed, you can talk about the very bloated and difficult to maintain the point. So take a chance to redesign it. The business logic in the project is more and more chaotic. Therefore, the architecture must be well-done to facilitate later maintenance.

Referring back to the view-layer architecture, we've been referencing a lot of information, including MVC, MVVM, and so on, and everyone's statements are not exactly the same. There is only one explanation, that is, the architecture pattern is not a constant, but a continuous development, as the project is also developing, the Code of the project is also being reconstructed. So, this article is not necessarily about the most realistic concepts of these architectures, but rather my understanding of them. The middle understanding may also have some problems, welcome to put forward and then perfect together.

At the same time, this article refers to the architecture of the iOS view architecture, and for Android and the web, and so on, although the principle is similar, but in the actual development process can be very large, and even the application is different. So it needs to be supplemented by other relevant personnel.

View Layer Architecture

When it comes to architecture, of course, MVC, followed by the development of the MVP, as well as the upgraded version of Mvcs, MVVM and so on. These architectures are actually all figured out, but in the process of learning there are always a lot of things that can not be clear, including their most primitive concepts, their development, and their applicability.

Mvc

MVC divides the architecture into three parts, model, view, and controller, respectively. It can be said that the three-tier architecture is the foundation of all the view-layer architectures, and the other models are developed from the three-tier architecture.

• View: Primarily responsible for the display of views

• Model: Mainly responsible for the management of data

• Controller: Reconciling view and model

MVC is an older pattern, so let's look at the basic structure of MVC first.

From what we can see is this chain of relationships:

• View passes interaction information to the Controller

• Controller notifies model to change data

• View from model get data display to view, model update data, notify View Update view

In fact, this is the most traditional MVC structure. In this structure, the view and model hold each other, and even the relationship between the view and controller and the controller and model are inextricably linked and very detrimental to maintenance. So, later MVC developed a new structure.

Now look at the new relationship chain:

• View passes interaction information to the Controller

• Controller notifies model to change data

• Notify controller to change data after model update data

• Controller informs view update view after data change

As you can see, the new MVC evolved removes the link between the view and the model, allowing the view to communicate only with the controller, and the model only communicates with the controller. This structure is also known as the heavyweight view controller structure, in addition to the View section and Data section, the rest is given to the Controller, will continue to talk about later.

So, what we call MVC, basically refers to the new view controller. Decoupling between view and model facilitates project development, so developers who are responsible for different modules don't have to worry about their own changes affecting others ' code.

Mvp

The MVP is developed from MVC, which is basically the same as the new MVC, with a detailed definition of the functions of each part of MVC and how they communicate, and the interface between the view and the controller.

In the MVP, the controller concept is replaced with presenter, the main function is to display the interface, but in fact, the controller is not much different.

MVP most important is a new layer of iview interface between view and presenter, and the view and presenter communicate through iview. When it comes to new MVC, view and model are decoupled, and in MVP, view and presenter are further decoupled. Let the view only the function of the view, and the controller only do the function of the controller, the two communicate through the interface, do not affect each other.

It can be seen that MVP and MVC are very similar.

MVCS

Mvcs is a development from MVC, Mvcs is not an enigmatic architecture, but the model of the data storage part of the store separate. Model is responsible for the management of data, while store is responsible for the storage of data.

MVVM

MVVM, although it does not have C in its name, does not mean that it does not have a controller. On the contrary, the Controller and the view in MVVM are closely connected and are integrated. Therefore, MVVM can be understood as MVCVM, or V in MVVM as a VC, i.e. view and controller.

The VM in MVVM refers to the ViewModel, which separates MVC from the business logic part of the controller and forms the ViewModel. In this way, only the part of the controller that is related to the view interaction is left, and the business logic, which is independent of the views display and the view interaction, is viewmodel.

So, controller and view together, and ViewModel to communicate with each other, and ViewModel again and model communication. In fact, such a way is very similar to MVC, which is the same view and business logic communication, business logic and data exchange.

An important concept of MVVM is data binding. Data binding makes it easier to communicate between views and ViewModel, which is equivalent to binding the view's data to the business logic, and any change to the other side will affect the other party's changes. Of course, data binding is not required, and it can be implemented using notifications, observer patterns, proxies, and so on.

Fat and Thin

Fat and thin, refers to whether a layer is bloated, contains a lot of logic, a lot of code. The more controversial is the fat model and the thin model, because the fat model means the thin controller, while the thin model means the Fat controller.

The thin model is a feature of MVC. Because model is only responsible for the data Management Section, if the model is large, you can separate the store, but how to divide, or data management. At this time, the controller is responsible for the view layer of interactive control, but also contains business logic (business logic is divided into strong business logic and weak business logic). So, the controller is naturally responsible for a lot of things.

The FAT model requires that the controller's weak business logic be moved to the model, reducing the burden on the controller. In this way, the controller is responsible for interacting with the view and strong business logic.

In fact, the fat and thin model, just determines the position of the weak business logic. The weak business logic of the thin model is placed in the controller, while the weak business logic of the FAT model is placed in the model.

Which one should we advocate?

In fact, weak business logic should be as independent as possible and use the FAT model. There are three reasons.

• Weak business logic should be separated from the controller, because it is difficult to wait until the controller is bloated.

• Weak business logic should be put into model, because model encapsulates the processing of data, and weak business logic belongs to the data processing part.

• Weak business logic is included in the model and remains independent, facilitates model maintenance, and facilitates testing of weak business logic.

So, when a logic you don't know which layer to write to, write to the model layer, so later want to refactor the words will be very convenient.

The key to architecture

The key to the architecture is only one word, which is "split".

In fact, the architecture is constantly evolving, each architecture is developed on the basis of the previous architecture, and from the above architecture, the architecture is similar and necessarily includes the view, model and controller.

A split to MV

A represents an application. At first, if the app is small, you might want to write all the code together. And the project is big, in order to facilitate management, it is natural to break it into model and view, because you know the model is the same, and the view will always change.

V Split to VC--MVC

When there is more view, or there is too much interaction logic in a view, you will consider taking the controller part of the view apart. Because view is sometimes constant, the interaction often changes. This method of dismantling is the embryonic form of MVC. As for how each layer communicates, you can define it.

M split for MS-MVCS

The model layer also becomes larger, which naturally also has to be torn apart, so the data storage part of the store. This becomes the Mvcs.

C Split to CVM, MVVM

After the controller gets bigger, it takes apart its business logic and the interaction logic, allowing the controller to only interact, while the business logic is encapsulated in the ViewModel. And it became MVVM.

M split for VMs and S-Mvvms

If you think that M is too big in MVVM, you can naturally take the model out of the store like Mvcs and name it Mvvms.

Summary

So, as long as you need, you can take out any layer of MVC, you can remove a layer or two layers, as long as you feel the need can be dismantled. So there is no such thing as too many architectures, and other architectures are new names that people have started to dismantle MVC.

Principle decoupling

Decoupling is necessary, and the coupling between any one layer is too large to be easy to maintain. Imagine that the controller inside the view and child views arbitrary call, while arbitrary call model property method, and the view layer and the model layer hold each other, one day want to modify the view, it is the heart of vomiting.

Interface oriented

Interface-oriented is important, but optional. Interface-oriented programming is advantageous for development and maintenance, but must be explicit in interface. Well-structured projects, for frequently changing modules, can create interfaces, which avoids the need to modify the code for each change. But if the project is not small, the project is not standardized, it is not very good to define the interface. There are times when some modules don't change much, and defining interfaces can add a lot of work.

Therefore, if you want to define an interface, you should take a set of specifications and define it as soon as possible.

Single principle

Put the same type of logic into the same module, and different logic does not put it in the same module. If you are working with a picture, write to the module of the picture, and if you are working with strings, write them into a string, rather than because they all solve similar problems or write to a file because they don't have a lot of code, then it will add a lot of maintenance costs later on.

Summarize

This time the study also let me gradually clear the code architecture, for the subsequent code architecture to do a good job.

For any problem, it is best to have a systematic study. But now there may not be much systematic information on the Internet, and the knowledge of books is easily obsolete. This requires us to quickly find a lot of information from the Internet, to study in categories, and to summarize as soon as possible. Sum up, in order to get real knowledge from it.

Resources

• Casataloyum:ios Application architecture on view layer organization and invocation scheme

• WINTER-CN: Talking about the evolution of UI architecture design

• Stackoverflow:what is MVP and MVC and what is the difference?

• Teehan_lax:model-view-viewmodel for IOS

• Know: Is the business logic handled in the MVVM mode in M or VM?

• Know: What is your understanding of MVC, MVP, and MVVM three combination modes?

• Indream Luo: From script to code Blocks, code behind to MVC, MVP, MVVM

• Objc:lighter View Controllers

• Yourcodesucksexception:why you should use MVVM instead of MVC

• XXDOTNET:MVP, MVC, MVVM, silly!

• Microsoft:presentation Model

• Wind: The difference between MVC and MVP

• Nanyi: Illustration of MVC,MVP and MVVM

• ... There are other too many, not listed.

Talk about the view layer schema