MVVM vs Bloc patterns

Question

I'm creating a new app with Flutter, and I'm trying to design it, separating the business logic from the view.

I've read about Bloc and MVVM (I know there are other patterns but these were the ones I preferred), but I don't understand the differences between them. They look pretty much the same to me.

Does anyone can help me understand them?

Lox

BLoC is pattern, that designed especially for Flutter according to specific of Flutter architecture. And yes - they are pretty same – Laundress

Answer 1

They are not quite the same, actually... MVVM implies databindings between the view and the viewmodel, which means, in practice, the view objects mostly are the ones commanding the viewmodel. MVVM seems to me a simplification of MVC, to show the model "as is" behind the scenes. For example, Xamarin largely uses MVVM and the controls on the screen like checkboxes, textinputs, etc, all do modify the modelview behind the scenes.

You may already starting to see a problem here: if you change the UI you may have to change the MV as well. Suppose you have an entry number that must be between 0-255, where do you put this logic? Well, on MVVM you put this logic on the view. But you must put these locks on the modelview as well to guarantee data safety. That means a lot of code rewriting to do the same thing. If you decide to change this range, you have to change in two places, which makes your code more prone to errors. Disclaimer: there are workarounds for this but is far more complicated than it should be.

On the other hand, BLoC works by receiving events and emitting states. It doesn't care (although it may) from where the event came from. Using the same example from the above, the view would signal an event to the bloc/controller with "hey, my number changed!", the bloc then would process this new event and, if suitable, emit a signal to the UI: "hey UI! You should change! I have a new state for you!". Then, the UI rebuilds itself to present those changes.

For me, the advantage of BLoC over MVVM is that the business logic can be entirely decouple from the view, which is overall a better way to do things. As our modern software development requires more and more changes in the UI (being different screen sizes, densities, platform, etc.), having the UI side decoupled from the models are a fantastic feature to code reusability.

Cosmotron

This is not true: "Suppose you have an entry number that must be between 0-255, where do you put this logic? Well, on MVVM you put this logic on the view." The very purpose of MVVM is to separate the logic and the UI. That's the exact opposite of what you'd do. – Corolla

That’s why we have a validate() method on the ViewModel. Business logic validations are not View domain. – Houseraising

Your mvvm comment is invalid. You would put the the limit in the view model and have the view use that as your one and only source of that limit. – Gog

For transparency, this question has 7 downvotes and 17 upvotes, where as the more popular answer has no downvotes at all. This note is both for me in the future when I inevitably come back to question related to architecture, and for others. 🙂 I found this answer confusing. – Abortion

I most certainly don't do input validation in the view! It's the view models responsibility to validate the input and return/expose an error. No code duplication and unit testable. – Lianeliang

For anyone reading in future, author has no clue what MVVM is. – Ocotillo

Answer 2

Looking at this illustration for MVVM (source):

You can see that there are seperate data and business logic models. However, using BLoC there is not really a distinction like that. The classes that handle the business logic also handle the data, which can also apply to MVVM.

To be fair, there really is not much of a difference. The key part to take away is the same for both: Isolating the business logic from the UI. Hence, the implementation of either of the two will look very similar, i.e. using Stream's and StreamBuilder's.
Additionally, there are packages that make working with Stream's easier, e.g. rxdart which is what the Flutter team uses as far as I am concerned.

Furring

If I get what you are saying, is Bloc is an implemetation of MVVM? – Lox

@Lox You can put it like that if you like. – Furring

Answer 3

BLoC and MVVM seemed to be different when BLoC was introduced, but that differences faded away as BLoC implementations changed over time. Right now the only real difference is that BLoC doesn't specify a separate presentation logic and business logic, or at least it doesn't do it in an obvious manner. Presentation logic is the layer that understands interactions between UI elements and the business part of the application(Presenter job in MVP). Some BLoC implementations put presentation logic into BLoC's, some others into UI.

The NEW THING in BloC was that it should not expose any methods. Instead, it would only accept events through its exposed sink or sinks. This was for sake of code reuse between Angular Dart web apps and Flutter mobile apps. This concept was recently abandoned because we don't really write Angular Dart web apps and it is less convenient than regular methods. Right now Blocks in official BLoC package expose methods just like good ol' VM.

Some would say that BLoC should expose one Stream of complete state objects, while VM can expose multiple Streams, but this is not true. Exposing one Stream of states is a good practice in both approaches. At first, official Google BLoC presentations presented BLoCs implemented using multiple output Streams as well.

One interesting difference that seemed to be a thing was that BLoC should communicate via events not only with UI but also with different parts of the application. for example, it should receive an event after receiving Firebase notification or when Repository data changes. While this seems interesting I've never seen an implementation like that. It would be odd from a technical point of view (Repository would have to know about all BLoC's that are using it???). Although I am thinking about trying out such an implementation that would be based on EventBus but that's completely off topic :)

Equivocation

Completely agree with you – Sukhum