Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Replace MVVM with MVC for the architecture pages #11438

Open
1 task
alefwd opened this issue Nov 24, 2024 · 3 comments
Open
1 task

Replace MVVM with MVC for the architecture pages #11438

alefwd opened this issue Nov 24, 2024 · 3 comments
Assignees
Labels
from.page-issue Reported in a reader-filed concern

Comments

@alefwd
Copy link

alefwd commented Nov 24, 2024

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:

Screenshot 2024-11-24 at 22 29 12

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:

Screenshot 2024-11-24 at 22 34 42

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.
@alefwd alefwd added the from.page-issue Reported in a reader-filed concern label Nov 24, 2024
@human2-0
Copy link

That's so elegant way, I wish I could see that when I was starting with Flutter

@Turskyi
Copy link

Turskyi commented Nov 25, 2024

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?

@afterwire
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
from.page-issue Reported in a reader-filed concern
Projects
None yet
Development

No branches or pull requests

5 participants