Why Swift Developers Don’t Need More Than MVC
Other architectures are fine, but MVC is all you really need
There are a lot of architectures and patterns out there. You’ve got MVVM you got MVP, VIPER. Each pattern and architecture is created to deal with specific scenarios or problems that are common to iOS Development, or software development in general.
Knowing various patterns and architectures is advantageous. But there’s a common misconception among many Swift developers. That misconception is that to be a good Swift developer you need to know tons of patterns and architectures. This makes some developers feel inadequate if they only use MVC.
Why a Good Swift Developer Doesn’t Need to Know a Ton of Patterns
“I prefer to use MVVM.” “No Viper would be better in this scenario.” “No, I think that MVC is best in all…
In the last article I wrote about patterns, RichG mentioned something very interesting. He said that they went to a meetup and poled 8 senior developers on what architectures they use. Every single one of them only used MVC. And all these Swift developers were senior.
So what does that mean?
It doesn’t mean that you must only use MVC to be a great developer. It means that you can be a great swift developer without using more than MVC.
But how is it that MVC can be adequate for all scenarios and circumstances you will face?
Benefits of MVC
MVC is a common architecture
Remember, not everyone knows all the patterns and architectures. And some are very complex. Not saying that you shouldn’t learn other architectures and patterns. You should understand how the other architectures work and their pros and cons.
But, one advantage of MVC is everyone knows MVC. It’s a pattern that's used across many different platforms and languages. My last job required a lot of ASP.NET development. We used MVC.
Very simple design
MVC is very simple. There’s nothing fancy or overly complex about it. It can be explained to almost any developer.
Simplicity is essential to development for many reasons, but especially from the standpoint of wanting to make people’s lives easier. The more complex your architecture, the more difficult it will be for others to understand and modify your code.
Since MVC starts from such a simple design, I find that code written using MVC is oftentimes more simple.
“Perfection (in design) is achieved not when there is nothing more to add, but rather when there is nothing more to take away.”
— Antoine de Saint-Exupéry
Also too, MVC is very straightforward. It’s very ‘what you see is what you get.’ Some patterns and architectures may provide more benefits, but there’s so much going on in so many different places that it can be overwhelming.
It’s self-explanatory what is accomplished within the model, view, and controller layers. This contributes to its simplicity.
If there are aspects of the codebase that have become overly complex, I find it easier to fix those issues if the codebase was architected using MVC. Due to MVC’s simplicity, it’s often very easy to find what needs to be broken apart into smaller, more modular sections.
Other architectures can be more complex which makes them more difficult to modify. However, this does depend upon how you implement MVC. You can still make your code overly complex and confusing if you don’t implement good design principles. No architecture can fix bad code.
Remember That Patterns and Architectures Don’t Have To Be Rigid
Just because you are using a specific architecture, doesn’t mean you can’t bend or even break the rules if necessary. When choosing an architecture such as MVC, you’re not stuck to a very specific set of guidelines. Let me show you what I mean for each layer of MVC.
The Model Layer
Some people use the Model layer of MVC to…
- Persist data
- Store data objects
- Handle networking tasks
- Storing constants
Now, this is fine. The question though, is how are you going to approach each one of these tasks? Using MVC does not mean that for every view controller there should be only one model class.
As with any architecture, the goal is good design principles.
Your model layer should consist of as many different objects as necessary to maintain good design principles.
For example, I always separate my networking tasks into two layers. The first layer is responsible for making the actual API calls. The functions in this layer always return or emit an object that consists of the response object’s id and its data as a dictionary.
The second, the higher-level layer, is responsible for communicating with the lower networking layer. It calls the functions in the lower networking layer and then converts the responses into local custom objects.
My view controllers only access the higher-level networking layer.
By doing this I reduce complexity and make my code more modular. It also keeps me from having massive view controllers, a common issue with MVC.
Now, you don’t have to do things my way. In fact, I’m not recommending that at all. All I want to illustrate is the fact that you don’t have to tie yourself down to a rule which results in poorly designed code. How you write your model layer is entirely up to you.
As far as views go, you can always split views into smaller components.
For example, say you have a complex view with many different UI elements. You can make that one single view, or you can split that into separate views. If you limit the references between the different views to a few references or none at all then you maintain modularity.
Often times, I find that my view classes are fairly basic. I write my UIs entirely programmatically, and I rarely have overly complex views. But my view classes are only responsible for displaying data. I don’t handle state in the view classes.
There are many ways to maintain good design principles with your view controllers.
Child View Controllers
With child view controllers, you can have one view controller made up of multiple child view controllers. This alone will decrease the size and complexity of your view controllers.
Using protocols helps maintain modularity and reusability.
Because you can implement multiple protocols you can basically create little building blocks and construct your view controllers off of multiple protocols. By doing this, you’re maintaining modularity.
There’s tons of other benefits to protocols that we’ll speak about later.
How Swift Developers Should Be Using Protocol Oriented Programming
Don’t force yourself to follow the rule, instead learn the principles
Separation of Concerns
Sometimes all you need to do is separate some of the view controller logic into separate classes.
For example, it’s very common to put UITableView data source and delegate methods within a view controller. That’s fine. You can do that if you want. But how about creating a separate object responsible for the UITableView delegate and data source methods? Then just reference that object within the view controller. And if you need to handle interactions, then you can use Reactive programming or observers to do that.
So try to keep in mind separating functionality across multiple objects instead of putting everything in your view controller classes.
By this simple change, you reduce the complexity of the view controller.
Learn from other patterns and architectures
In each article I write that touches on patterns and architectures, I always make it a point to mention that all patterns and architectures have value. I am always doing research on patterns and examining architectures. I don’t do this so that I can apply rigid rules to my codebase. My goal is to understand how different architectures and patterns fix common problems while maintaining good design principles.
Once I understand the pros, the cons, and the motives behind specific designs, I am able to implement these principles into my own codebase.
No architecture is going to fit perfectly throughout the lifetime of a project. You’ll always need to bend the rules. Otherwise, you’ll run into problems.
The massive view controller issue with MVC is due to the fact that people mistakenly believe that if some code doesn’t fit perfectly in the model or view layer, then it must go in the view controller.
But you do that enough, and you have a massive view controller. The fix to this is remembering the importance of modularity and separation of concerns. Putting a ton of functionality into your view controllers is destined to break these principles.
By separating the view controller logic in whichever way you see fit, you’re able to maintain good design principles while still technically falling in the lines of MVC.
MVC is the first architecture that iOS developers learn. But that doesn’t mean that it’s a tool that should only be used by new developers. MVC offers many benefits, and by applying good design principles, you can avoid many of its cons.
Always remember, that whatever architecture you choose, you can deviate, bend, and break the rules. Rules help you to grow when your knowledge is limited. But as your knowledge and experience grow, you’ll find instances in which rules don’t always apply to your unique situation.
As a skilled developer, you can adapt MVC to fit whatever situation you find yourself in.
Don’t fall into the trap of believing that to be skilled you must implement other architectures. It’s just not true. Focus on understanding what the difference is between good and bad code, and you’ll be able to adapt to any situation using only MVC, or whatever other architecture you chose.
If you enjoyed this article, then clap for it. Some people don’t know you can clap up to 50 times for the same article. Try it!