I like to MVVM it MVVM it

Patrick O'Leary
Aug 9, 2017 · 5 min read

A lot of my writing about code involves the smaller aspects of building an app. Things like cool frameworks, idiomatic Swifty things. Not a mention of the overall way to structure a project. Today, that changes.

Ch ch ch… changes!

There are several common design patterns for the overall structure of an app. Model-View-Controller is the simplest and probably most common. You have a view, which represents the user interface, a controller, which controls the logic of the UI, and a model, which represents an object or some data. The view talks to the controller which talks to the model. The model and the view are never in direct communication. This is great, but the downside is that a lot of the logic is handled by the controller. The often results in massive amounts of code within our View Controllers, and can lead to confusion about which part of your program is responsible for which part of the logic. This is where MVVM comes in.

MVVM stands for Model-View-ViewModel. It adds an extra step of abstraction in between your model and the view controller. In this pattern, your views talk to the view controller, as before in MVC, letting the VC know of any user interaction. The view controller then talks to a view model, which in turn talks to the model. In this case, all of the business logic is removed from the view controller and placed in the view model. The controller now just has two jobs: to inform the view model when a user interaction has occurred within a view, and to inform the views when to update, using the data provided to it by the view model.

Dig it!

So those are the basics. Next is to figure out a way to get each of these steps — the model, view model, and view/view controller — to talk to each other. One common way is to use a Functional Reactive Programming framework. FRP is way beyond the scope of this week’s post, so I won’t go into it. It’s a very cool way to think about coding, so if you’re interested, you should definitely check out ReactiveSwift and RxSwift. I also just came across ReactiveKit, which seems to be a little more lightweight, and possibly a little easier to jump into if you haven’t seen reactive programming before. I’ve been looking for an excuse to get into a reactive framework, and I may just have found it.

Just jump right in!

Another way to get your view/view model/model components to talk to each other is through Key-Value Observing. I talked about KVO last week. We establish our models as having observable properties, and add observers to those properties onto our view models. The view models then perform whatever logic is necessary on the properties, then they themselves will update some observed property, which the view controller is observing. The method has some definite pros and cons. On the plus side, you maintain a high level of independence between each layer of your MVVM architecture. Your classes/structs will be very self contained and easy to test. The downside to this is that KVO in Swift inherits a lot of ugliness from Objective-C. While it did significantly improve in Swift 3, and more improvements are coming in Swift 4, the syntax feels unwieldy compared to most operations in Swift. Personally, I think the pros far outweigh the cons, but you’ll frequently hear developers complaining about using KVO in Swift.

I don’t want to write KVO!

A third option — albeit one that I haven’t seen too many developers use in MVVM — is to use the delegate pattern to implement MVVM. If you are unfamiliar with the delegate pattern using protocols, here’s a good summary I found. Your view model will have an instance of the model it’s using for information. The view model declares itself as a delegate of the model. Anytime the model updates, it fires off a function that is declared in the ‘ModelDelegate’ protocol, and implemented within the view model. The same relationship happens between the view model and the view controller. Delegation also has some pros and cons. A big con is that you’re very deliberately coupling the model to the view model, and the view model to the view controller. This takes away some of the independence of each level of the architecture. You’re forced to be very deliberate about when to update the views. The separation of logic becomes less clear, which slightly defeats the purpose of using MVVM in the first place. The benefit of using delegation is that protocol oriented programming is one of the things that Swift is all about. The syntax is simple, and it’s hard to misread what your intent is.

So now that we have the basics of MVVM down, I’ve built a project for you to glance over if you want to see how this actually works. It’s probably easier to read if you see it in an actual project, so here’s a link to the github repo. All I’ve done is take last week’s example on KVO, and refactored it using MVVM architecture. The Model and View Model communicate via KVO, while the View Model and View Controller communicate through the delegate pattern.

So that’s MVVM! I think it’s a good way to structure a project. As always, leave any questions or comments below, and I hope you have a rad week!

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade