IOS design mode-MVVM

IOS design mode-MVVM

If you have been developing iOS applications for some time, you may have heard of MVVM or MVC (design mode ). This is the standard mode for building iOS apps. However, recently, I have become increasingly tired of some shortcomings of MVC. In this article, I will sort out what MVC is and its shortcomings, and tell you a new way to organize your applications: (that is) MVVM.

Model-View-Controller-MVC (Model-View-Controller) MVC constructs your code through clear examples, Apple even said so. In MVC mode, all objects are divided into models, views, and controllers. The model stores data. The view provides an interactive interface for users. The View Controller coordinates the interaction between the model and the view.

In the illustration, the view serves as the Controller that notifies any user interaction. The View Controller then updates the model to reflect the state changes. Then the model (usually through key-value observation) notifies all controllers that they need to update their views. This coordination method forms a lot of code written in iOS applications.

Model objects are usually very simple. Most of the time, they are core data management objects, or if you prefer to avoid core data and other common models. For Apple, the model uses the data and logic to process the data. In practice, the model is often sparse, whether it is good or bad, the controller gets the logic of the model.

A view (usually) is one of the UIKit components defined by a programmer or a set of UIKit components. They are usually pieced together into your. xib or. Storyboard: Components for visual interaction with applications. Button. Label. You have an idea that the view should never be directly referenced by the model, and the Controller should trigger the event only through IBAction. The business logic that does not belong to the view itself should not be there.

In this way, we discard the controller. The Controller is the "adhesive code" of an Application: It coordinates all interactions between the model and the view, and the Controller manages the view hierarchies of their own views. They respond to view loading, appearance, and disappearance. They tend to use model logic for loading, so we can avoid moving our models and business logic away from our views. This is our first problem with MVC...

Large-scale View Controller

Because the amount of Code placed in the View Controller is very large, they tend to become very bloated. The code in some view controllers in iOS may extend to thousands of lines of code. These bloated fragments in your application weigh off: large-scale view controllers are hard to maintain (because they are too large) and contain many attributes, it makes their status difficult to manage and conforms to many protocols, mixing the Protocol response code with the Controller logic.

Large-scale view controllers are difficult to test, either manually or in a unit test, because they have many possible states. It is usually good to divide your code less and make it easier.

Network logic missing

The MVC definition-the one Apple uses-specifies that all objects can be classified as a Type, a view, or a controller. All of these. So, where should you put the network code? Where does code communicate with APIs?

You can try to put it in a model object cleverly, but doing so may become tricky, because network calls should be asynchronous. So if a network request goes beyond the model that owns it, well, it becomes complicated. You should never put the network code in the view, so... It should be left to the Controller for processing. This is a bad idea, because it will prompt us to generate a large-scale View Controller.

So where? For the code, none of the three components of MVC is suitable for the code.

 

Another major problem with poor testability MVC is that it does not encourage developers to write test cases. Since the View Controller's view operation logic is mixed with the business logic, separating these unit tests has become an arduous task. All agree to ignore this task (unit test )... So we didn't test anything. Fuzzy definition of "Manage"

 

The View Controller that I mentioned earlier manages the view level. The View Controller has a "View" attribute and can access the subview of the View through IBOutLets. This expansion is not very good, because when you have many outlets, and in some cases, you may still use the subview controller to manage all your subviews. So where? When will it be helpful to split and refine things? Does the business logic verify that the user input is a controller or a model? There are many vague lines here, and it seems that no one can fully agree. When you draw these lines, it seems that there is no problem, and the view and its corresponding controller become so closely coupled, then you might as well regard them as a component. Hey! Now I have an idea... Model-View-ViewModel (MVVM)

 

In an ideal world, MVC can work well. However, we live in a real world, and this is not the case. Now, we have introduced in detail how MVC breaks the typical usage. Let's take a look at another method: Model-View-view model.

MVVM comes from Microsoft, but do not resolutely oppose using it. MVVM is very similar to MVC. It gives the view and controller a certain form of tightly coupled nature, and introduces a new component.

In MVVM, views and view controllers are formally connected; we use them as a component. The view still does not reference the model, but does not reference the controller. Instead, they reference the view model.

The view model is a good place for user input verification logic. It presents logic, additional network requests, and other complex code through the view. One thing is that the view itself does not belong to any view reference in the view model. This logic in the view model should be equally applicable to iOS and OS X. (In other words, do not import UIKit. h In your view model. You will be fined ).

The presentation logic, such as ing a model value to format a thing-in the view model, the View Controller itself will become very large, but not bloated. The best part is that when you use MVVM, you can place a small part of the logic in your view model, and migrate them when you become an increasingly suitable example.

IOS applications written using MVVM are highly testable. Because the view model contains all the Demonstration Logic and does not reference this view, it can be fully tested by programming. Although many hackers are involved in testing the Core Data model, applications written in MVVM can perform unit tests.

In my experience, the result of using MVVM is that the total amount of Code increases slightly, but the overall complexity of the Code decreases. This is a very accounting method after the trade-offs.

If you look back at the MVVM diagram, you will find that I use ambiguous Verbs "notice" and "Update", but there is no expenditure. You can use KVO, just like MVC, but it will soon become difficult to manage. In practice, using ReactiveCocoa is a good way to bond all modules together.