Why does Flow not support common patterns like MVC/MVP/MVMM?

Flow
1

So the question actually is why does Flow (or some Module) not support the user in programming with (at least one) common patterns like MVC/MVP/MVMM?
Currently when programming (without the designer) with Vaadin, I’m missing a clear distinction between Model, View and that what’s in between, missing an optional structural restriction, leading in some cases to messier code then (in my opinion) necessary. So whats the point?

Is it just my personal missing discipline or is it the maybe the framework encouraging though it’s simpleness (front- and backend together) bad coding habits? Well Vaadin got the Designer, it creates a (much clearer) line between “presenter” and View, but it still requires mapping to the Java side which does not make it “super clean”. Also not everybody is able to use the Designer, so this shouldn’t (at least in my opinion) be the only solution.

So I was wondering if there was (or may be) a (official) way to assist the user in developing better coding habits.

[I came up with this for now]
(https://github.com/appreciated/mvp-flow/blob/master/src/main/java/com/github/appreciated/mvp/Presenter.java) but ofcourse this is just WIP. It would be really nice if this (or something similar) could end up in Vaadin. CDI related things are ofcourse another story, since it uses other mechanisms.

Any Ideas?

2

Hi,

I don’t know if you are already read this article: https://vaadin.com/blog/is-mvp-a-best-practice-

I like to separate a UI in multiple layers:

  • Presenter: This class got all the UI logic, the actions and no import com.vaadin
  • The “view”: Got binder, @Route, click listener (that call presenter method)
  • Form: View layout (like the generated Vaadin designer view)

In your add-on I like the fact that it’s really simple (in my opinion the most important thing).
But I’ve got the feeling that a lot of code will be in Presenter. For example for a form with a pojo, the model will be fairly simple, the view will also be simple and will have actions, binder, validators, …

I think you should not create a MVP because it’s a common pattern (which one MVP) but to solve a problem. As you may have different problem, you may use different pattern.

3

So the question actually is why does Flow (or some Module) not support the user in programming with (at least one) common patterns like MVC/MVP/MVMM?

I find this question rather odd, since Vaadin as a framework is somewhat agnostic what comes to this kind application level questions.

With Vaadin 10+ you can implement your application by MVC/MVP pattern equally well than you did it with Vaadin 8. The structure is not enforced by the framework, but neither it is having anything that makes it impossible.

When using templates (with Designer or other means) the MVVM (Model View View-Model) pattern is becoming more natural i.e. View being the template and View-Model the Java side implementation.

As this topic is opionated and there is no absolute thruth which pattern is the best (and that is why frameworks in general should be agnostic to this), my recommendation usually is that, select a pattern that fits your application and be consistent with it.

4

In your add-on I like the fact that it’s really simple (in my opinion the most important thing). But I’ve got the feeling that a lot of code will be in Presenter. For example for a form with a pojo, the model will be fairly simple, the view will also be simple and will have actions, binder, validators, …

So (as Tatu Lund suggested), would MVVM be better in this case?

I think you should not create a MVP because it’s a common pattern (which one MVP) but to solve a problem. As you may have different problem, you may use different pattern.

Well I guess this depends on the answer to: “What is better some (frontend-)pattern or no pattern at all?” to which I guess there is no general answer, since it depends a lot on the Usecase. But my solutions does not force the user to use a pattern. Maybe this could also be seen as a way to make the user actually think about their usecase. Since Java also provides interfaces for some general patterns as well so why not providing some in Vaadin?

Tatu Lund:
With Vaadin 10+ you can implement your application by MVC/MVP pattern equally well than you did it with Vaadin 8. The structure is not enforced by the framework, but neither it is having anything that makes it impossible.

Maybe supporting was not the proper wording, I meant supporting in the way of helping (reducing boilerplate). Not in the way that the frameworks hinders the user. So yes Vaadin does not hinder the user in using common patterns, but it also does not encourage the user.

since Vaadin as a framework is somewhat agnostic what comes to this kind application level questions.
But why is it being agnostic about this? Doesn’t the UX (user being the developer) suffer from this?

Since every user of Vaadin has the “problem” in finding a fitting pattern, one could argue since the framework does not help the user, this will lead to more boiler plate. Some users might not even be interested in finding a proper pattern for their application, these users might be writing bad code.
Providing some basic structure (as an example can be seen in the addon) for the most common patterns, could be a way to reduce boilerplate code, and possibly help the “uninterested” user in writing better code.

When using templates (with Designer or other means) the MVVM (Model View View-Model) pattern is becoming more natural i.e. View being the template and View-Model the Java side implementation.

As this topic is opionated and there is no absolute thruth which pattern is the best (and that is why frameworks in general should be agnostic to this), my recommendation usually is that, select a pattern that fits your application and be consistent with it.

Ofcourse you got a point there is no holy grail in the frontend pattern department, but this is not what this is about. This is more about development comfort and how it could be improved. You might also be right that MVVM might be the better choice here.