You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I understand this request is opinable, and debatable, because it depends on the definitions we use, but when I presented Flutter Architecture Components, which was inspired by Android Architecture Components, I realised the Android's MVVM model doesn't apply to Flutter, while the MVC is more representative of how Flutter works.
Let's stick to some generic definition of the MVVM and MVC patterns.
1 We can see from this picture:
that an MVVM requires data binding between the view and the view model. This is old legacy, coming from Android using xml as binder between the UI and the data (side note: now with Compose, someone should tell the Android team to reconsider the MVVM pattern as well).
"Declarative data and command-binding are implicit in the MVVM pattern. In the Microsoft solution stack, the binder is a markup language called XAML.[10] The binder frees the developer from being obliged to write boiler-plate logic to synchronize the view model and view. When implemented outside of the Microsoft stack, the presence of a declarative data binding technology is what makes this pattern possible,[5][11] and without a binder, one would typically use MVP or MVC instead and have to write more boilerplate (or generate it with some other tool)"
2 We can see from this picture:
that the MVC represents more precisely (than MVVM) the cycle where the user clicks the UI, which access the controller to manipulate the model, and after the manipulation the UI is notified and gets updated.
"If user input prompts a change in a model, the controller will signal the model to change, but the model is then responsible for telling its views to update"
"The controller responds to the user input and performs interactions on the data model objects. The controller receives the input, optionally validates it and then passes the input to the model"
3 This is argumented not only by me here, but also by Christian here, by Thomas here, and many others. I think these 3 comments from Ahmed summarise it well.
4 I have a repo with an entire app build with MVC here, if someone wants to have a look.
Expected fix
In my best wishes, I would like to see the MVVM taken away from the guide, and replaced with MVC
Additional context
No response
I would like to fix this problem.
I will try and fix this problem on docs.flutter.dev.
The text was updated successfully, but these errors were encountered:
I appreciate the discussion on Flutter architecture, but I disagree with replacing MVVM with MVC. First, Flutter’s architecture guide is a big step toward standardization—having a consistent guide is better than none.
Second, while you argue MVVM isn’t suitable for Flutter because it lacks binding, the same strict logic applies to MVC: Flutter’s UI acts as the controller, making MVC just as incompatible.
Third, Android’s architecture isn’t explicitly MVVM, so suggesting a shift away due to Compose misrepresents its guidance.
Finally, I believe MVP is a better fit than both MVC and MVVM for Flutter. Simply renaming “ViewModel” to “Presenter” would align with definitions while keeping the guide intact. Perhaps the request could be reframed to propose MVP instead?
I think the entirety of the Bluesky thread you linked to actually provides a number of very compelling counterpoints against this issue and I have to agree that this entire debate feels entirely unproductive and just catering to the (very strong) opinions of a tiny minority of folks.
Page URL
https://docs.flutter.dev/app-architecture/guide#mvvm
Page source
https://github.com/flutter/website/blob/main/src/content/app-architecture/guide.md
Describe the problem
I understand this request is opinable, and debatable, because it depends on the definitions we use, but when I presented Flutter Architecture Components, which was inspired by Android Architecture Components, I realised the Android's MVVM model doesn't apply to Flutter, while the MVC is more representative of how Flutter works.
Let's stick to some generic definition of the MVVM and MVC patterns.
1 We can see from this picture:
that an MVVM requires data binding between the view and the view model. This is old legacy, coming from Android using xml as binder between the UI and the data (side note: now with Compose, someone should tell the Android team to reconsider the MVVM pattern as well).
"Declarative data and command-binding are implicit in the MVVM pattern. In the Microsoft solution stack, the binder is a markup language called XAML.[10] The binder frees the developer from being obliged to write boiler-plate logic to synchronize the view model and view. When implemented outside of the Microsoft stack, the presence of a declarative data binding technology is what makes this pattern possible,[5][11] and without a binder, one would typically use MVP or MVC instead and have to write more boilerplate (or generate it with some other tool)"
2 We can see from this picture:
that the MVC represents more precisely (than MVVM) the cycle where the user clicks the UI, which access the controller to manipulate the model, and after the manipulation the UI is notified and gets updated.
"If user input prompts a change in a model, the controller will signal the model to change, but the model is then responsible for telling its views to update"
"The controller responds to the user input and performs interactions on the data model objects. The controller receives the input, optionally validates it and then passes the input to the model"
3 This is argumented not only by me here, but also by Christian here, by Thomas here, and many others. I think these 3 comments from Ahmed summarise it well.
4 I have a repo with an entire app build with MVC here, if someone wants to have a look.
Expected fix
In my best wishes, I would like to see the MVVM taken away from the guide, and replaced with MVC
Additional context
No response
I would like to fix this problem.
The text was updated successfully, but these errors were encountered: