First thing first, MVC stands for Model View Controller.
“Everything should be made as simple as possible, but not simpler.” by Albert Einstein
Why software architecture?
As a developer, I more concerns on how the software modules communicate or interact each other, rather than how effective the code to achieve a task. I am not saying quality of code is not important, but in fact I want to point out how important of software architecture for the quality of code. The reason is simple, maintenance. Everything will change, including Swift language, business logic, data structure, and etc… If you cannot respond the change on time, you lose the opportunity. And this situation will become worser and worser, if your project grows up bigger and bigger, without any strategy.
Why MVC?
There are many different software architecture in iOS world, such as MVC, MVP, MVVM, MVVMC, VIPER, Redux, and etc… We will go through these architecture one by one in later episodes. If you search MVC on google, you may find a lot of information saying that MVC is bad, or the really name of MVC is Massive View Controller. I am not writing to flight back these arguments here, but I would like to share with you few points about MVC:
- MVC is one of most Apple recommended design pattern in iOS¹ (here Apple use the phase “design pattern”, instead of “software architecture”)
- Other different architecture evolve from MVC, which is the foundation or origin design. If you can master it, it can help you better understanding others.
- There is no perfect solution or silver bullet for software architecture. If people argue among them, it implies that there are always Pros and Cons or trade-off of them. For example, you won’t see people arguing for taking horse-carriage or fuelled vehicle. It is because we already have the solution for this problem. (Personally I am not suggesting current consumer economy and harm the earth)
What is MVC?
When you start a new project using storyboard, Xcode will always provide you a temple of UIViewController, which is an entry point to control your application and its life cycle. You may probably put all of your code in this viewController. That is fine if your application is simple or the line of code is under hundreds. Unfortunately, if your application grows up more and more UI components and logics inside your single viewController, it will easily be more than thousands of code there. And then you will be difficult to develop further, even though to resolve the bug on this. In this way, you should refactor your program in certain kind of software architecture, which can help you managing your code better.
The concept of MVC is simple, there are only 3 kinds of modules in your program for specific tasks:
- Model, mainly corresponding to data structure
- View, mainly handling UI stuffs
- Controller, take care about the rest of issues: such as business logics, life cycle, delegate and etc…
In this role play, view and model will never talk each other directly. They can only communicate via controller.
Talk is cheap, show me the code
Here is a simple “To Do List” application. The basic functions of this app are input a new event and delete the event from tableview. We use delegate pattern to receive user action from the view and notification from the data model. If you are not familiar with protocol-delegate pattern, you are welcome to visit my article on it.
From the Xcode’s project navigation, we have separated the code according to the MVC principles.
- Looking at view controller, the codes focus on initialising the view and model objects, setting up delegations and controlling business logics.
- Inside the ToDoView, all the code are responsible to the UI modification, and convey the user interaction to view controller.
- For the ToDoModel, it is simple data model with add and delete functions, and notification to view controller if there is any data change.
Conclusion
MVC is one of the simple and popular software architectures, but it is not a silver bullet to handle all kinds of project and application. In the following episodes, we will demonstrate how to migrate this “To-Do-List”project into other architectures. If you are interested, please subscribe.
