There are a lot of articles about different architecture patterns for mobile applications which try to convince you that this or that architecture pattern is the best one. Sure thing, we all know that there is no a silver bullet… unfortunately. However, it’s a very good exercise to compare the most popular mobile architecture patterns (MVC, MVP, MVVM, VIPER, Riblets and Redux) and find out:
- what we can learn from them,
- how they can help us to design our app architecture.
Multitier architecture
In order to compare the above mentioned architecture patterns we need a baseline. I chose the multitier (actually 5 tier) architecture as it’s very popular, universal and has tiers/layers that are in fact very high level abstractions so we can use them to understand the abstraction level of the layers in mobile architecture patters.
There are a lot of information about the multitier architecture [1], depending on the type of system some authors find 3 layer (pure backend — Data, Business Logic, Presentation), some 4 or 5.
Each layer is a high level abstraction and the architecture has only one restriction: components in the layer can interact only to the components from the neighbour layers. It allows to decrease the coupling between parts of the application and keep a dependency graph in a manageable state.
So let’s map each mobile architecture pattern to our baseline and see what we can find out.
MVC
Let’s start from MVC: View can be easily mapped to the View layer, Controller we can map to Presentation layer, and Model then should span over the rest of layers and it depends on your product whether you need them or not (in most cases you do). So MVC adds nothing to the multitier architecture and actually just simplifies it a bit.
MVP
Next is MVP. We can map it in the same layers as MVC — just change Controller to Presenter. Additionally, MVP restricts interactions between components so that Model can interact only with Presenter and View can interact only with Presenter as well. In the multitier architecture we have the same restrictions, so MVP again adds nothing.
MVVM
MVVM has a pretty similar mapping. View, as in the previous examples, can be mapped to View layer, View Model in this pattern usually maps to Presentation layer and Model is the rest. The only difference is in a more advanced decoupling between View and ViewModel — here ViewModel knows nothing about View and all interactions from ViewModel to View happen through the binding of UI elements in View layer components to exposed properties in ViewModel components. So MVVM adds conception of binding between View and Presentation layers to the multitier architecture.
VIPER
What about VIPER? It looks like a different beast. View as always maps to View layer, Presenter and Router go to the Presentation layer, Interactor maps to Business logic, and, Entity spans over Service and Data layers. Thus VIPER adds Router layer that helps to extract routing business logic from Presentation layer. But, what is more important, VIPER introduces conception of VIPER modules and describes a universal structure for such a module in an app and by this it starts the confusion between layers and classes names (Interactor usually is a class name that doesn’t make sense as it this name can’t help us to understand the business logic inside the Interactor). Splitting the app to modules is a very useful concept but there is no clear understanding how those modules can interact with each other and moreover share some state.
Redux
Redux seems to be the only pattern that doesn’t cover View at all and concentrates mostly on Business logic as Reducers and State, and, Data + Service Layers as Middleware. Redux is a very good attempt to define the conception of building the “backend” part of our layered model(data, service and business+state layers). By introduction the concepts of state, subscriptions, reducers, actions and middleware Redux helps to fully decouple Business layer from Service and Data layers, and additionally, View + Presentation layers from all the other layers. So Redux doesn’t claim to be a universal architecture pattern, it just provides a way to organise interactions between the layers and keep them independent from each other.
Riblets
Lastly there is Riblets (or RIBs). This pattern can actually be 1–1 mapped to the layered model, Services maps to Data + Service layer, Interactor to Business logic layer, Model Stream looks like State inside Business layer, Presenter and Router maps to Presentation layer and View is actually View layer. Riblets looks very similar to the VIPER as it helps to split your application not only to the vertical layers but horizontally to modules as well. However Riblets fixes some VIPER problems and modules can be united to the hierarchical structure using Routers and communicate and share some state using Interactors.
Wrap up
How this analysis can help us to choose or understand existed mobile architecture patterns? Good question.
Firstly, we can see that not all the design patterns are on the same level of abstraction and moreover they have different intention.
MVC and MVP are very high level design patterns, they are on the same level of abstraction as the multilayered architecture and add nothing to it. So it worths to be aware that Model, View, Controller and Presenter are not the classes but rather abstract layers and you need to come up with the components, classes and interactions between them in each layer of the multitier architecture. They are just hints how you can split functionality of your application.
MVVM is more about interaction between ViewModel(Presenter) and View. If you want to isolate UI from components in Presenter layer — you can try the MVVM way of binding.
VIPER might help you to divide your app into modules with the strictly defined structure and interactions between components in the module. So it’s a lower level of abstraction and it has less freedom and flexibility if you follow VIPER ideology but it’s good as a starting point to learn about modularisation.
Redux is the only design pattern that takes the state and the business logic very seriously. Again Redux is located on the even lower level of abstraction and will considerably restrict you in a way of layers/components interaction if you chose it as it is. But Redux gives us an idea about the state and the business rules management and additionally it can be easily coupled with any of above patterns in this role (for instance, you may try to use Redux as a Model layer in MVP pattern).
Riblets seems to be on the lowest level of abstraction and it dictates you how to make hierarchical modules in your app, how to build them, interact between components in a module and even tries to take care of the app state. So if you think of you application as a hierarchy of modules and you have no idea where to start — it’s time to learn Riblets and see how it’s done there.
References:
[1] https://en.wikipedia.org/wiki/Multitier_architecture, https://www.researchgate.net/figure/The-5-tier-Architecture-model_fig1_280235378, https://www.oreilly.com/library/view/core-j2eetm-patterns/0130648841/0130648841_ch06lev1sec1.html
Top comments (0)