The MVVM architecture and Reactivecocoa framework for the MVC slimming--ios

MVC = Massive View Controller?

There are jokes called MVC as the heavyweight attempt controller. To be careful, there is a real problem. Take Uitableviewcontroller and UITableView for an example.
In general, we do not need to create a custom TableView inherited from UITableView. This means that the view module is almost blank. (in quite a few times, view is just a xib file or a bunch of code to describe the control's appearance and the position of the control). As for model, very similar to JavaBean, a class, a number of attributes and constructor enough. The processing of a large amount of business logic is placed in the view controller.

The purpose and inadequacy of MVC

Initially we wanted to be able to separate views, models, and manage both with a single view controller. However, the ideal is plump, the reality is very bony. Actual programming, encountered a variety of strange situations.
For example:

1. Where do I put the network request?
2. Where is the transformation of the data logic placed? For example, convert an array of type Nsarray into a NSString object and show it.

Be aware that the view controller is used to manage the view. Let it deal with these messy logic, is not too bloated, tube too much of their own should not be responsible for things.
Moreover, almost all views and view controllers are one by one correspondence. Since the view is inseparable from the controller, the controller must also maintain a view of its own management, why not simply combine them?

The new design structure--MVVM

In simple terms. MVVM is an optimized MVC, which means it can be compatible and essentially an MVC structure.
The so-called MVVM architecture is the separation of content that controllers should not be responsible for. Alone as a piece. In the terms of MVVM, the potentially complex process of "converting Model data into View can be rendered" is stripped out and placed into the ViewModel object. As for Viewcontroller, well, you're in charge of your view. You are not responsible for anything else. (therefore, the network request should also be stripped away, put into the viewmodel, in fact, a network request, but a number of models that are not stored natively, from JSON to the data that can be displayed directly on the view).
The view model (ViewModel), whether literal (ViewModel) or from its specific functions and implementations, is still a model, which provides data that can be used for view, extracts data from the model, and transforms it into processing.

Using a simple chain structure to represent the MVVM schema is
View/viewcontroller ———— > ViewModel ———— > Model
Here the Viewcontroller object holds a ViewModel object directly. The ViewModel object also holds the model object directly. Arrows cannot be reversed (this is the basic requirement of the MVVM schema).
This leads to a problem, how to inform Viewcontroller when ViewModel change, and change the view accordingly? This is what the REACTIVECOCOA framework is going to do. How does the model change inform ViewModel? The amount ..... Does the model need to change? The amount ... Must have to change, continue to use Reactivecocoa not on the line.

Where is the Reactivecocoa sacred?

Take an example in C language code

    int1;    int2;    int c = a + b;    printf("c = %d",c);

The output is obviously "C = 3".
If you change the code, add a line.

    int1;    int2;    int c = a + b;    a++;    printf("c = %d",c);

Obviously the output is still "c = 3".
If we want C to always be equal to the sum of A and B, attention is always equal. So for now, the only way to do this is to re-execute C = a + B every time A and B change. This is a hassle, and fortunately, in iOS development, OC provides the KVO mechanism, and the REACTIVECOCOA framework takes advantage of this mechanism and makes a variety of expansion.

How strong is the REACTIVECOCOA framework?

Simply put, imagine that a circuit has a power supply, a switch, and several small bulbs in series. Disconnect the switch, all the bulbs go straight off, what a simple thing! Because the light and dark of all the bulbs is directly dependent on the state of the switch. While 10 people live in 10 rooms, one must notify the other nine people each time they get up: "I'm up." What's the Huck?

Give an example of a practical development. Suppose there is a registration interface, the registration button becomes available only if the user name password that you enter satisfies some kind of logic. Usually we need to implement the proxy function of the text box, for each time the text changes, execute the judgment function to modify the state of the button.

In the dynamic, responsive framework of REACTIVECOCOA, what we're going to do is bind the button's Enabled property to Username.isvalid && Password.isvalid.

This logic is really great, in the next chapter, we explore the actual use of the REACTIVECOCOA framework.

The MVVM architecture and Reactivecocoa framework for the MVC slimming--ios