iOS MVC Pattern – Proper Implementation Guide

I'll speak specifically to iOS as it has its own concepts and some language features make its way of doing things a good fit. Often in iOS the Controller - Model layer interactions are based on some variant of Observer pattern (key-value observing (KVO) but also NSNotification). I find the model layer often doesn't engage in the same type of interactive back and forth that happens in the View - Controller layer interface (think the complexity of a dynamic, fully-featured table view), so delegation is not the most natural fit. Usually something (user input, a network request, etc) changes the model, and the controller responds accordingly by updating the view. But delegation is still used in long-running, dynamic interactions such as a table view that displays the contents of a frequently updating data set (see NSFetchedResultsController).

As to your question of having the controller be the delegate of your view and your model, there's no inherent problem other than you'll degrade the cohesion of your controller, and it sometimes becomes a good choice to split the controller layer into view controllers and data controllers. Using KVO or NSNotification to observe changes in the model layer is usually straightforward enough that you won't find a pressing need to extract a new class.

I am only just approaching these questions myself but I will give the best answers I can and make some observations.

We are told that iOS' MVC expects us to break our program up into models, views and controllers which link specific views to specific models. Sadly, in practice we will have a number of views and a number of models but only one (View)Controller taking care of all the linkages. This is what leads to massive ViewControllers.

Adopting MVVM in this context means breaking the ViewController up into two parts. The part that deals directly with Views (which stays in the ViewController class proper,) and the part that deals directly with Models (which is moved into the ModelView class/struct.)

This means that only the ViewController should be sending/receiving messages from/to the Views and the only non-view object the VC should be conversing with is the ModelView. While the ModelView should be conversing with all the various Model objects and should never converse with a View.

The above notion of the ViewController/ViewModel split leeds to the following answers to your questions:

1. No, your MVVM implementation is not correct. Your ViewModel methods have a fundamental flaw. They should not be talking directly with any view objects so they aren't in charge of showing the user any alerts. That's the ViewController's job. The ViewModel also isn't in charge of transitioning between ViewControllers.

2. The ViewController should not be dealing with any model objects. It should only be conversing with Views and the ModelView. Therefore, the ViewController should not be pulling the username and password out of it's views and passing them to the ViewModel's login function. That would require the ViewController to understand something about the differences between Usernames and Passwords and when it is appropriate to use them.

Instead, the ViewController should inform the ViewModel when changes occur in the username and password fields. It should inform the ViewModel when the login button is pressed. It shouldn't have any knowledge about what model objects the viewModel needs in any particular method.

3. I would expect the validate() function to return a Bool (better to call it isValid and make it a computed property.) I would expect the login() function to accept two blocks (one for pass and one for fail.) It can communicate what happened by calling the correct block. Another option would be to have the function accept one block as a parameter with a success boolean. So something like this:

-

struct LoginViewModel {

    var username: String = ""
    var password: String = ""

    init(username: String, password: String) {
        self.username = username
        self.password = password
    }

    var isValid: Bool {
        return !username.isEmpty && !password.isEmpty
    }

    func login(callback: (error: NSError?) -> Void) {
        let api = ApiHandler()
        api.login(username, password: password, success: { (data) -> Void in
            callback(error: nil)
            }) { (error) -> Void in
                callback(error: error)
        }
    }

}

4. In the MVVM paradigm, ReactiveCocoa (and RxSwift is another library) are used to communicate changes in the ModelView back to the ViewController, but let me ask you this... Does your ModelView ever change in any substantive way that your ViewController doesn't know about? So far, I have not been in a situation where any other object is sending messages to my ModelView other than the ViewController it is attached to, so there isn't any way for the ModelView to mutate without the ViewController knowing it's at least possible. Because of this, I generally have an updateUI() function in my ViewController. Every time my ViewController sends a potentially mutating message to the ModelView, it then calls updateUI() which examines the ViewModel and updates the UI accordingly. No need for any tricks.

- Hope this helps you and hopefully my answer will stimulate some discussion on this question.