Reference for this article:

IOS Architecture Patterns – A Brief introduction to MVC, MVP, MVVM and VIPER

Brief introduction to MVC, MVP and MVVM architecture patterns

In the whole GUI programming world, MVC has been around for nearly 50 years and has produced many variations, such as MVA, MVP, MVVM, and so on. In fact, there is no clear definition of MVC, and there are various MVC architecture diagrams circulating on the Internet.

The framework idea of MVC itself is very excellent. When there is a problem, the first thing to consider is not to replace the existing framework, but to optimize the existing code and logic from the point of view of design, so that the whole system can achieve an optimal combination.

Not long after learning iOS development, I began to contact MVC, the most famous and widely used architectural pattern. I also began to understand other architectural patterns.

The MVC, MVP, and MVVM patterns all group all entities into one of three categories:

  • Models – The data access layer responsible for holding data for processing. Think of the Person, PersonDataProvider class.

  • Views – Is responsible for the Graphical User Interface. On iOS, you can view all classes prefixed with UI.

  • Controller/Presenter/ViewModel – responsible for coordinating the interaction between the process Models and Views.

Let’s start with a few different MVC’s

ASP.NET MVC:

ASP.NET MVC Overview describes the MVC pattern.

Based on this figure, I can simply understand as follows:

View shows the contents of the Model; The Controller manages the View and Model.

Spring MVC:

Unlike ASP.NET, Spring MVC implements the MVC architecture pattern more complex, adding a DispatchServlet for distributing requests and managing views:

The relationship between Model, View, and Controller can be understood as:

The controller layer and view layer are completely decoupled by DispatchServlet. There is no direct relationship between the view layer and the model layer, but only an indirect relationship. The model is queried by the controller, returned to DispatchServlet and then transmitted to the view layer.

Cocoa MVC:

Ideally Cocoa MVC without going into detail, Realistic Cocoa MVC is actually known as the heavy Controller pattern. Although the View and View Controller are technically different components, they almost always go hand in hand, in pairs. We normalize this schematic:

In fact, the code THAT I actually wrote, a lot of the logic was actually put in the View Controller.

If, for your small project, you don’t want to spend a lot of time designing the architecture, and you don’t want to spend a lot of money maintaining it, Then Cocoa MVC is the pattern of choice.

Cocoa MVC is the best architectural pattern for speed of development.

The MVVM:

In a typical MVC application, a lot of logic is stored in a View Controller. Some of them are View Controllers, but a lot of them are what’s called “presentation logic,” which in MVVM terminology is what converts Model data into something the View can present, For example, convert an NSDate to a formatted NSString.

There’s something missing from our diagram, something that would allow us to put all the representation logic in there. We’re going to call it “View Model” — it sits between the View/Controller and Model:

  • The MVVM architecture treats the ViewController as a View.
  • There is no tight coupling between the View and Model

MVVM is essentially an enhancement of MVC, where we formally connect the View and Controller and move the presentation logic out of the Controller and into a new object, the View Model. MVVM sounds complicated, but it is essentially a carefully optimized MVC architecture.

Its specific use needs to be supplemented after practice ~

Finally, the advantages of several architectures are summarized

Characteristics of a good architecture:

  1. Strict division and balanced distribution of roles and responsibilities between entities
  2. Strong measurability
  3. Easy to use and low maintenance cost

  • Cocoa MVC:

  • Partition – The View and Model are indeed separated, but the View and Controller are still tightly coupled.

  • Testability – Due to poor partitioning, you may only be able to test your Model.

  • Ease of use – Minimum amount of code compared to other modes, plus low barriers, everyone can master it, even if it’s not a very experienced developer.

About these points I deeply agree, especially the third point, this is also the predecessors taught me to improve efficiency. Coupled with the advantages of speed of development and not having to spend too much time designing the architecture, Cocoa MVC became one of the prime choices for outsourcing companies.

  • MVVM:

  • Partition – Views in the MVVM framework are more responsible for things than in the MVP. While the ViewModel updates its state through data binding, the ViewModel simply hands over all events to the Presenter and does not update itself.

  • Testability – Because the ViewModel doesn’t know anything about the View, it’s easy to test it. View should also be testable, but maybe because of its UIKit dependency, you’ll just skip it.

  • Ease of use – in real life MVVM is more concise. Under MVVM, you can update the state of a View with bindings.

Notes slightly rough content, in fact, and I do not understand deeply have a great relationship, more accurate, deeper content still need to keep learning and practice!