How to build a good IOS architecture by learning from the old IOS architecture?
Some of the history
In 1979, Trygve Reenskaug proposed MVC — a general solution to the problem of user control over large and complex data sets. The initial paper generated a lot of interest, and eventually many companies and individuals came up with their own understandings and implementations of MVC ideas that were not limited to the original definitions of Model, View, and Controller.
The original MVC
The 1979 paper describes MVC as follows:
Models
Model stands for cognition. Model can be a single object (a single object) or some structure of an object. “Models represent knowledge. A model could be A single object (rather uninteresting), Or it could be some structure of objects.”
Views
The View is a (visual) representation of its Model. It usually highlights some attributes of the Model and hides others. “A view is A (visual) representation of its model. It would ordinarily highlight certain attributes of the model and Suppress others.”
Controllers
The Controller is the link between the user and the system. It provides input to the user to arrange the relevant View to be displayed in the appropriate place on the screen. “A controller is A link between A user and the system. It provides the user with input by arranging for relevant views To present themselves in appropriate places on the screen.”
PS: Controllers were originally named Editors, but they changed their name later.
Sounds familiar so far…
Surprising fact in MVC:
Controllers
The Controller takes the user’s output, converts it into appropriate messages, and passes those messages to one or more Views. “… The controller receives The user’s output, Translates it into the appropriate messages and passes these messages on to one or more of the views.”
So the Controller knows and updates the View.
A Controller should never supplement Views, for example, by connecting the nodes of its View with arrows drawn to the screen. “A controller should never supplement the views, It should be for example never connect the views of Nodes by drawing Arrows between them.”
So the Controller should have nothing to do with visual representation.
The Controller is connected to all its views, which act as parts of the Controller. “A controller is connected to all its views, they are called the parts of the controller.”
This means that as long as the Controller creates the View and is not injected, it probably knows about the Models.
. This Editor is very similar to the previous Editor, but it is created in the network. Therefore, messages for the network and all of its activities can be typed and executed directly through methods. “… This Editor is very similar to the previous one, but it has been created in the environment of a demonstration network. Messages to that network and all its activities May therefore be typed in and executed directly through the “doit” command.
If we know that Editor is the old name of the Controller, and consider that “network” and “activity” are Models, we can conclude that the Controller does know and update the Model.
Views
The View is attached to its Model (or part of the Model) and gets the data needed for the display from the Model. It can also update the Model by sending appropriate messages. “… A view is attached to its model (or model part) and gets the data necessary for the presentation of the model by asking Questions. It may also update the model by sending appropriate Messages.”
So Views knows and updates Models.
Surprise!
Let’s put all the pieces of the puzzle together:
How does it look?
- It breaks some good software design practices.
- Implementation in iOS is impractical.
The transformation of MVC
Single responsibility
Views and Controllers are responsible for updating the model, but we want only one entity to have this responsibility. This is why one-way data flow is proposed:
Loose coupling and high cohesion
Views knows Models. Controllers know Models and Views. In this case, Models rely on Views and Controllers. This means that when we modify the interface to the Model, we have to modify the Controllers and Models. But ideally, we want to minimize the number of entities affected by our changes, so we want to minimize the dependencies between them. According to the Law of Demeter, we want one character to know as little as possible about the other characters, and they interact with each other through friend classes rather than directly. From there, we can remove the View’s ability to change the Model and let the Controller take care of it.
The original MVC was impractical — especially in iOS
The original MVC allowed the View and Controller roles to be implemented by the same object:
In the simple case, the Model, View, and Controller roles can be implemented by the same object. “In simple cases, the Model, View, and Controller roles may be played by the same object.”
UIViewController completely takes over the role of the speaker for all roles. So Apple’s MVC seems to follow the original MVC idea, except that the input comes mostly from UIControlls (belonging to Views) rather than Controllers. If we compare them, they look the same:
Having two responsibilities for an object causes us to keep most of our business logic in one object. If not caught in time, this approach can end up with bloated ViewControllers. Although there is a separate Model entity, developers are often unaware that the Models are the primary maintainer of the business logic and do not use the Model to completely separate the other entities.
Learn from MVC
MVC becomes very useful if we think of it as a pattern rather than a good architectural guide. In fact, there are a lot of things that are “right” in MVC.
Separation of concerns
MVC defines three roles, or responsibilities, that are a broad overview of how users interact with devices or applications. If we look at it at an abstract level rather than talking about implementation details, the responsibilities of models and Views are very clear. Meanwhile, the Controller’s responsibility is questionable and seems to be an intermediary between the Model and View that processes user input.
Facade (Facade pattern)
MVC uses a Model to represent a user’s mental Model of a real object or phenomenon. The Model contains the data and the logic for how to change it. This logic is often referred to as business logic. People tend to ignore the logic, just turn the Models’ data into objects, and then let the Controllers manipulate all the logic, causing the Models to get thin and the Controllers to get fat.
The appropriate Models are collections of objects and data that are actually the true source of the entire application.
A Facade is an object that hides a group of other objects, just as the front of a building hides many of the rooms inside. When the Facade pattern is applied, the interaction of these objects is done entirely through Facade objects, just as people enter and exit a building through a Facade entrance. We avoid direct access to hidden objects, just as we avoid jumping through Windows to get into a room faster.
The Facade prevents business logic from leaving the Model layer and moving to the Controller layer.
Observer mode
One of the techniques for removing dependencies from Models is the Observer pattern. The top-level idea is that a Model doesn’t know who is using it, but simply notifies potential users of something happening or data changing through notifications or callbacks. The simplest way to understand the observer pattern is to imagine an object that uses a radio station to broadcast changes and other objects that use a radio to listen to the signals.
service
Mediator
Let’s look at the role that Controllers play: Models and Views. Do we still need Controllers? No Controllers would cause us to access Models directly from Views, which would violate the single liability principle. In addition, it is difficult to write test cases because Views are platform-dependent (UIKit, etc.), and whenever you want to test the code in Views you have to consider handling the lifecycle of Views in UIViewController. Instead, we set Controllers as intermediaries between Models and Views. They are very thin and lighter than Models and Views because they know Models and Views, so they have more dependencies than Models or Views. Of course, the more dependent an object is, the less logic you should put in it. Taking on less responsibility will reduce complexity and thus the chance of mistakes. As a result, Controllers become a light but sometimes dirty glue between Models and Views.
The development of the MVC
Let’s look at how MVC roles are assigned in the existing architecture.
Make sure you read the iOS architecture design article so we can understand each other.
Apple’s MVC
MVP/MVVM
VIPER/Riblets.
Service/Storage/store (Service/Repository/Storage)
Presenter(Presenter)
Router = Router
conclusion
Don’t try to think of MVC as a single architectural design pattern, but as a guideline for good application architecture, or as a set of design patterns that can solve some of our problems.
Make sure you are not only able to explain a pattern in an interview, but also understand how that pattern solves practical problems in your everyday life as a programmer.
Design patterns appropriately during development (to improve code quality). Remember the principle of YAGNI (You ain’t Gonna Need it, You don’t Need it) rather than pick an architecture and shoehorn your application into it.
Avoid blindly copying frameworks (such as VIPER/Riblets) into real projects and consider the growing needs of the real business. Rigid code creates tons of redundancy. Remember, we can always divide roles between entities, but avoid doing so if we don’t have to.
Templates are designed to enable users to retrieve information or interact with the system, not to make developers lazy. Also, avoid producing “final code” (tomorrow is not the end of the world). You might use today’s code as the basis for tomorrow’s new features.
Thanks to a certain author for this article: Extensive MVC Investigation Article [RU], which inspired me to write this article.
Thanks for reading this article from 🚧Do MVC Like It’s 1979