Detailed description of MVC and MVVM modes in iOS development
In iOS, Model-View-Controller divides software systems into three parts: Model, View, and Controller.
Model: What is your application essentially (but not how it is displayed) Controller: How your Model is displayed to the user (UI logic) View: What the user sees is manipulated by the Controller
The Controller can directly access the Model or directly control the View. However, the Model and View cannot communicate with each other.
View can access Controller through action-target. For example, we drag UIButton in StoryBoard to @ IBAction created in the Code. When the button is clicked, View will pass this information to the Controller. Sometimes the Controller needs to monitor the View status in real time. In this case, the Controller sets itself as the View's delegate through protocol, in this way, when View will change, shocould change, and did change, the Controller will also receive corresponding notifications. View does not store data, but views can be obtained through the Protocol rather than the data in the Model for display. The Controller organizes the data in the Model for display to the View.
The Model cannot communicate directly with the Controller, because the Model exists independently of the UI. However, when the Model changes, you can use the broadcast mechanism to notify the Controller. In iOS, NSNotification and KVO (Key-value observing) are available.
NSNotification:
LetCenter =NSNotificationCenter.Defacenter Center()
Center.AddObserverForName(UIContentSizeCategoryDidChangeNotification,
Object:UIApplication.SharedApplication(),
Queue:NSOperationQueue.MainQueue())
{NotificationIn
LetC = notification.UserInfo? [UIContentSizeCategoryNewValueKey] }
UIContentSizeCategoryDidChangeNotification andUIContentSizeCategoryNewValueKey is a String defined in the system.
KVO:
In ViewDidLoad:WebView.AddObserver(Self, ForKeyPath:EstimatedProgress, Options:. New, context:Nil)
Override FuncObserveValueForKeyPath (keyPath:String?, OfObject object:AnyObject?, Change :[NSObject:AnyObject]?, Context:UnsafeMutablePointer<Void> ){ If(KeyPath =EstimatedProgress){ ProgressView.Hidden=WebView.EstimatedProgress=1 ProgressView.SetProgress(Float(WebView.EstimatedProgress), Animated:True) } }
The MVP mode evolved from the classic MVC mode and replaced the Controller with the Presenter. According to the explanation in the MVP Baidu encyclopedia, the advantages of MVP compared with MVC are completely separated between Model and View, the Model and View information can only be transmitted through the Controller/Presenter. I found that the MVC mode of View and Model on other platforms can communicate directly with each other, but in iOS development, that's what Apple says. In MVC, all objects are classified as a model, a view, or a controller. The Model holds data, and the View displays the interface for user interaction. The View Controller mediated the interaction between the Model and View. In iOS development, I cannot communicate with each other according to the Model and View.
MVVM (Model View-Model)
Demonstrate the differences between MVVM and MVC.
In iOS development in MVC mode, the Controller undertakes too much code, including our view processing logic and business logic.
In MVVM, we extract the View processing logic from C to V, and the rest of the business logic is called View-Model. The testability of iOS applications using MVVM mode is better than that of MVC, because ViewModel does not include View updates. Compared with MVC, ViewModel reduces the burden on the Controller and makes functional division more reasonable.
The correct practice of MVVM mode is that we should create a ViewModel for the Root View of app delegate. When we want to generate or display another secondary ViewController, use the current ViewModel to create a subviewmodel for it.
The ViewModel code is not stored in ViewController. Our View requests our ViewModel to obtain the required data. ViewController is totally attributed to View.