Model-view-viewmodel for IOS [translate]

If you've been developing iOS apps for a while, you've probably heard of Model-view-controller, or MVC. MVC is the standard Model for building iOS apps. Lately, however, I've been getting tired of some of the drawbacks of MVC. In this article, I'll revisit what MVC is, detail its shortcomings, and tell you a new way to architect your App:model-view-viewmodel. Take out your pop-up bingo card (bingo, a game card-translator's note), as we are about to make a paradigm shift.

Model-view-controller

Model-view-controller is an authoritative paradigm for organizing code. That's even what Apple says. Under MVC, all objects are categorized as a model, a view, or a controller. The model holds the data, the view shows the interface that interacts with the user, and the view controller mediates the interaction between the model and the view.

In, view notifies the controller of user interaction. The view Controller responds to state changes by updating the model. Model (usually using key-value-observation) notifies the controller to update the view that they are responsible for. Most iOS application code is organized in this way.

Model objects are usually very, very simple. Most of the time, they are core data managed objects, or avoid using core data, which is another popular data model layer. According to Apple's documentation, the model includes business logic for data and operational data. In practice, the model layer is often very thin, however, the business logic of the model layer is dragged into the controller.

Views view is typically a collection of Uikit controls (component, which are interpreted as controls here), or Uikit controls that are defined by encodings. Enter. Xib or storyboard will find that an app, Button, and label are made up of these visually and interactively controlled controls. You know. View should not refer directly to model, and only use the Ibaction event to reference the controller. The business logic clearly does not fall into view, and the view itself does not have any business.

There are also controller controllers. The controller is the glue code of the app: coordinates all interactions between the model and the view. The controller is responsible for managing the view hierarchy of the views they own, as well as responding to views of loading, appearing, disappearing, and so on, often with model logic that we don't want to expose, and business logic that doesn't want to be exposed to the view. This leads to the first question about MVC ...

Heavy-weight View Controller

Because a lot of code is put into the view controller, they become quite bloated. There are hundreds of thousands of lines of code in the view controller in iOS that have never been seen before. The projections for these overweight apps are as follows: Heavy view controllers are difficult to maintain (due to their sheer size), contain dozens of attributes, make their state difficult to manage, and follow many protocols (protocol), The response code that causes the protocol is confused with the logic code of the controller.

Heavy view controllers are difficult to test, either manually or using unit tests because there are too many possible states. Breaking the code down into smaller modules is usually a good thing.

Lost network logic

The definition of MVC used by Apple is that: all objects can be categorized as a model, a view, or a controller. That's it. So where do you put the network code? Where should the code that communicates with an API be placed?

You might try to put it in the model object, but it can be tricky, because a network call should use Asynchrony, so if a network request is longer than the model life cycle that holds it, things will become complicated. Obviously, the network code should not be placed in the view, so only the controller is left. This is also a bad idea, because it exacerbates the problem of heavy view controllers.

So where should we put it? It is clear that the 3 components of MVC have no place to put the code at all.

Poor testability

Another big problem with MVC is that it does not encourage developers to write unit tests. Because view controller mixes view processing logic and business logic, unit testing that separates these components is a daunting task. Most people choose to ignore this task by not doing any tests.

Define a fuzzy "Manage"

I mentioned earlier that the view controller can manage the hierarchy of attempts, the view controller has a "view" property, and can access any child views of the view through Iboutlet. This is not easy to extend when there are many outlet, and in a sense, it is best not to use Child view Controller to help manage the child view (Subview).

What's the point? Verify that the business logic entered by the user should be included in the controller or model?

There are a number of vague criteria here, and no one seems to be able to agree completely. In any case, the view and the corresponding controller are tightly coupled, in short, they will be treated as a component.

hey! Now there's an idea ...

Model-view-viewmodel

In an ideal world, MVC might work very well. However, we live in the real world. Now that we have elaborated on the problem of MVC in a typical scenario, let's take a look at an alternative: Model-view-viewmodel.

MVVM comes from Microsoft, but don't stick against it. MVVM is like MVC. It formally regulates the nature of the tight coupling of views and controllers and introduces new components.

In MVVM, view and view controllers are formally linked, and we treat them as a component. View views still cannot refer to model models directly, and of course controllers cannot. Instead, they refer to the view model.

The view model is an excellent place to put user input validation logic, view display logic, initiate network requests, and a variety of other code. One thing that should not fall into the view model is the reference to any view itself. The concept of view model applies to both iOS and OS X. (In other words, do not use the #import UIKit.h in the view model)

Because the display logic (presentation logic) is placed in the view model (such as the model's value mapping to a formatted string), the view controller itself is no longer bloated. The best way to start using MVVM is to put a small amount of logic into the view model and then migrate more logic into the view model as you get used to the paradigm.

iOS apps that use MVVM are highly testable, because the view model contains all the presentation logic and does not reference view, so it can be fully tested programmatically. While there are numerous hack technologies involved in testing the core data model, apps written using MVVM can be fully unit tested.

In my experience, using MVVM can slightly increase the amount of code, but overall it reduces the complexity of the code. It's a bargain.

Looking back at the diagram of MVVM, you'll notice that I used the vague verb "notify" and "Update" without detailing what to do. You can use KVO, just like MVC, but it will soon become difficult to manage. In fact, using REACTIVECOCOA would be a better way to organize the pieces.

For information on how to combine Reactivecocoa with MVVM, you can read Colin Wheeler's excellent write-up or look at the open source app I wrote. You can also read my book about Reactivecocoa and MVVM.

Original link

Model-view-viewmodel for IOS by Ash Furrow

Extended Reading

[1] http://wearebase.com/an-introduction-to-mvvm-and-reactivecocoa-on-ios/
[2] http://blog.sunnyxx.com/tags/Reactive-Cocoa-Tutorial/
[3] http://objccn.io/issue-13-1/
[4] Http://limboy.me/tech/2014/06/06/deep-into-reactivecocoa2.html
[5] Https://github.com/ReactiveCocoa/ReactiveCocoa