What is the difference between MVI compared to MVC and MVVM

Question

Is there a difference between the "newer" Model-View-Intent architecture compared to the "older" ones like MVC and MVVM?

What issue does MVI address? What are the similarities with MVC/MVVM? What are the differences?

There are similar questions already on stackoverflow for MVC/MVV/MVP but none so far that explains MVI.

What is the difference between MVC and MVVM?

What are MVP and MVC and what is the difference?

Answer 1

from my experience each architecture pattern of those was invented to solve specific problem that the previous one ignored or wasn't observed yet.

MVC - Model View Controller

in UI applications the responsibilty of rendering the data to the screen, or the business logic and bind those together at first wasn't clear. so MVC came to define those responsibility to three components, each one has one purpose, and the picture describe the relation between those three components.

View - is the UI component that has all the properties like color, shape, tools to listen to the click events .. etc.

Model - is the component that define the business logic that you want the view to render and behave accordingly.

Controller - is the one who change the model, so if the view has a name for example to save, View pass it to the controller then controller manipulate the model with the right actions.

MVP - Model view presenter

the problem with MVC that there is a great coupling between the three components, if you want to change the view calls, it will require you to update controller and the Model. and that's clear from the MVC picture, the relationship between the three components is very tied, you couldn't replace one of those components without the other. So MVP came to provide a more clean solution to the previous problem by separating the Model and the View, keep the interactions between them via the Presenter, Presenter is the middle man that each the view and the model call. So if you want to save a list of favorites movies, View listen to user (*) action, then call the presenter function that update the model, then model tells the Presenter if that succeed or not, and Presenter tells the View to show the right message.

MVVM - Model View ViewModel

with the rise of reactive paradigm, it was clear that we can provide more separate of concerns in UI Applications by just observing the changes and behave on it. so for example there is a click in view that need to call an api to get latest tv shows.

this view click will be observed at the ViewModel, ViewModel interact with the model to get the data, and finally ViewModel post those data on the view using other observer ..

so in short, View observe ViewModel to get UI updates, and ViewModel observe View to call the right action with the Model. Observer pattern has proved his worthy in decoupling logic so here you go a new Pattern.

---

So after talking about the most popular architecture patterns, each one has tried to decouple the UI code from the business code. but the previous patterns doesn't bound updating UI with different states in the same time.

if you had an issue that related to the loading appear with an error message showed at the same time, you will understand what I'm talking about, so to maintain UI state, you have to do extra effort looking what you wrote wrong causing those kind of issues.

MVI - Model View Intent

MVI is based on an old idea called finite state machine, any system or component has predictable, set of states is a finite state machine. in MVI any update to the UI is defined by new state, you could find this is overwhelming, but imagine that you have a screenshot for each time UI changes, that's the state. you can debug, test, reproduce the state issues now.

how to achieve this, that's the MVI in practice. any user interaction with the UI, is defined in MVI by an Intent, Intent is what the user need from this action, it could be star a movie, refresh the screen, it even could be opening the screen, in that case the Intent is an initial intent to show the screen with all required data.

which component get those Intents to act according on them, that what you define .. you could use a Presenter or a ViewModel, it doesn't matter, MVI is more a practices than using a new middle component.

I'll continue with ViewModel, ViewModel will get those intents, decide which usecase to call (Model behaviors).

all usecases pass by summer function in the ViewModel, that decide which state that needs to be reflected to the View, it provides you with previous state too, so you have the previous and the new state to update the screen, which reduce the rendering updates, and View get only the new hints to update itself.

and finally MVI is uni directional flow, it starts with the View and ends with the View.

... View -> ViewModel/Presenter -> Model -> View -> ...

MVI is different in the way of managing the state, it's a combination of several ideas to build more stable, and testable app.

Answer 2

A really great breakdown is here: https://academy.realm.io/posts/mvc-vs-mvp-vs-mvvm-vs-mvi-mobilization-moskala/. At it's core, MVI is taking the ideas of MVVM (stateless UI state), separate business logic and models, and putting the reactive framework on top of it. Making things streams of events instead of discrete actions, making receiving elements consumers of transformed streams instead of presentation elements, and making state a read-only, disposable thing that is acted upon explicitly in a very structured way.

This requires that you take a functional approach to writing your application, especially the UI/View part of things. State is not modified, new state is calculated from an intent and a series of use-cases. This is fairly well explained here: https://proandroiddev.com/mvi-a-new-member-of-the-mv-band-6f7f0d23bc8a.

It is intended to address the growing complexity of modern UI applications, who have a non-trivial amount of client-side state that needs to be managed explicitly. As most experienced programmers know, the most complex failures come from state that is being modified in an unexpected way. This state manipulation can result in "invalid" states that your application cannot handle, which is effectively a crashed application. MVI addresses this by making state transitions explicit and carefully structured so that they system never comes to an invalid state, and the state is always understandable.