Design patterns make your app’s code more modular and forgiving when it comes to bug fixes and changes. In this article, you’ll be learning about the MVC (Model-View-Controller) and the MVVM (Model-View-ViewModel) design patterns.
Although design patterns (also known as architectural patterns) are key for the development of scalable Cocoa Touch apps, there is a lot of controversy around which architectural pattern is actually best for use in your app.
Check out these recent posts by Bart Jacobs on MVC and MVVM for more perspectives on these design patterns and the choice between them.
-
Why MVC Might Not Be the Best Pattern for Cocoa Apps
-
Put Your View Controllers on a Diet With MVVM
The collection of objects of a certain [architectural pattern] in an application is sometimes referred to as a layer—for example, model layer. — Apple
Without further ado, let’s take a look at a few of the design patterns that you can use in your next app.
MVC (Model-View-Controller)
This is the most commonly used pattern in Cocoa Touch development, and it’s also my personal favorite. This design pattern efficiently and effectively sorts out your code into three categories (or layers): the Model, the View, and the Controller.
How Does It Work and Why Should I Use It?
With this design pattern, you can make changes to one layer without affecting the other layers of the pattern. For example, if you need to change the database, you’d just remove the model and replace it without having to edit the view or controller. Or if you want to change the way a view looks, you don’t have to worry about messing up the database code. This is called “separation of concerns”, and it makes your code easier to debug, maintain, and reuse.
In addition, this is the design pattern that is recommended by Apple themselves, and it’s a norm in the iOS development community. If you’re just starting out, I highly recommend just sticking to this pattern. You can try out different design patterns later in your Cocoa development career.
Layers and Responsibilities
Let’s take a closer look at the different layers in this pattern and what each one is responsible for. Here’s a quick diagram of the interactions between the layers:
The MVC design pattern separates each part of your code into one of three parts: the Model, the View, and the Controller.
- Model: This layer is only responsible for the data and its form as it appears in your app. The Controller layer can make changes to the app data by notifying the model. The model is not responsible for anything else, including how the data is shown to the user or who or what uses the data.
- View: The View is responsible for the representation of the data—only how the user sees and interacts with the data. This can include reusable cells, tables, and other user interface elements which know nothing about the data or how it’s being handled. The data is supplied to the view elements by the Controller.
- Controller: The Controller is the star of the show. It brings data from the Model and then passes it on to the View to be displayed to the user. This is the only layer between the Model and the View, which can cause some issues, which we’ll look into later in this article. The Controller is typically implemented in ViewController.swift, and it is responsible for listening to input and changing the model as needed.
One thing to keep in mind is that you shouldn’t cram too many responsibilities into any one of these layers because that would defeat the purpose of having a design pattern!
Also, if you don’t keep the connections between the layers clean and clear, you’ll end up with a messy and unmaintainable app, despite using the MVC design pattern! In particular, make sure you don’t let the view and the model communicate directly. These interactions must happen solely through the Controller.
MVVM (Model-View-ViewModel)
Although the Model-View-Controller design pattern is pretty common and should work for most cases, it comes with its own set of challenges and drawbacks. Because of this, we have another design pattern called MVVM, which stands for Model-View-ViewModel.
MVC Is Great, So Why Do I Need MVVM?
Well, there’s one major problem which you should be aware of. As you saw in the previous section, the Controller layer is the only layer between the View and the Model, so it’s not surprising that people abuse this layer and quickly give it too many things to do. This might seem like the easiest thing to do at the time, because it avoids changing the other layers, but eventually it leads to a bloated Controller and difficult-to-maintain code.
This has led to MVC being given the whimsical nickname “Massive-View-Controller” in some circles.
The MVVM architectural pattern, which was borrowed by Cocoa developers from Microsoft, can help combat this problem of massive view controllers. Though it isn’t as common in iOS development as MVC, it’s increasingly being used to make up for the shortcomings of MVC.
Layers and Responsibilities
Let’s take a look at the different layers and their responsibilities in MVVM. (You should probably note that in the Cocoa community, there aren’t any formal guidelines on how to use these layers.)
Here’s a quick diagram demonstrating the layers of this architectural pattern and their connections to one another.
If you think about it, you’ll see that even though views and controllers are separate layers in the MVC design pattern, they are very closely coupled. So in MVVM, we simply take the View and the Controller and combine them into one layer.
Let’s compare each layer to its counterpart in the MVC pattern.
- (View) Controller: This layer, usually just known as the View, is tightly connected with the Controller. So much so that they aren’t even separated into different layers! The View only communicates with the Controller, but the Controller communicates with the ViewModel and the View. The View and the Controller do the same tasks as in MVC, but the difference is that some tasks which were given to the Controller (in MVC) are now handled by an intermediate layer, the ViewModel, to prevent misuse of the Controller. The View still handles the display of data to the user, and the Controller responds to user events and communicates with the rest of the layers of the pattern.
- ViewModel: This layer does not actually contain any “views” on its own, but instead handles the logic behind showing views—usually called presentation logic. This includes creating custom formatting and processing strings to display, as well as actually crunching numbers to be shown to the user based on the data in the Model layer.
- Model: The Model isn’t very different the Model layer in the MVC pattern. As we saw before, the Model only handles the data and makes changes to that data if it receives updates from the ViewModel layer. It does not know anything about who’s using the data, what they’re doing with it, or how the user sees the data.
As you’ve seen previously, you shouldn’t mix the responsibilities of any of these layers as this can cause your app code to spiral in complexity, making the use of any design pattern redundant.
Conclusion
I hope you enjoyed learning more about these foundational design patterns for iOS. Hopefully, you gained a better understanding of the MVC and MVVM design patterns and are confident enough to use these in your future applications.
Of course, the architectural pattern which you use for your app is totally up to you, and it depends on the type of application that you’re trying to develop. However, if you’re new to iOS development, I still highly recommend sticking to the MVC design pattern because it is still the most mainstream in Cocoa development.
While you’re still here, be sure to check out some of our other tutorials and articles here on Envato Tuts+!
-
iOS SDKWhy MVC Might Not Be the Best Pattern for Cocoa Apps
-
Mobile DevelopmentPut Your View Controllers on a Diet With MVVM
iOS SDK3 Terrible Mistakes of iOS Developers
iOS SDKPassing Data Between Controllers in Swift
Powered by WPeMatico
