Application Architecture (model-view-presenter or not)

I’m wondering what the current best practices would be regarding application architecture for Vaadin 24 applications.

I like the MVP pattern, and I’ve used it on smaller projects … but I’ve noticed that although there was an architecture chapter discussing mvp in the old docs (vaadin 8), it’s no longer there in the newer docs.

Would love to see more articles discussing architecture.
Does anyone have good resources about this in a Vaadin context?

Also interested in topics like when to use @SpringComponent for views / components and when not, or guidelines on when to use the different Scope options, etc etc.

Or maybe, I just need to spend a bit more time on these topics, and write the articles myself :slight_smile:

If you have a Spring Boot application, you should use @SpringComponent on a view only if you want to use a scope Ui scope or Route scope. By default, it’s basically a prototype. Session scope or singleton won’t work for a view ( it will share the same components for multiple tabs in a browsers and that’s bad).

For MVP, the article written in Vaadin 8 should work also in Vaadin Flow. To me the architecture should solve an issue. So there is not one MVP and you shouldn’t apply it “automatically” to any application. This blog post is a great: Is MVP a Best Practice? | Vaadin

I tend to split my view layer into 3 parts:
The view ( contains the binder, notifications, validation)
The presenter ( actions that calls the service layer then asks the view to refresh)
The form ( when the form is big)

Of course sometimes the form is a bit too much. Sometimes you have a form with 10 tabs and 3 classes is not enough. I wouldn’t try to have one architecture for these 3 cases. But that’s only my opinion :slight_smile:

1 Like

Thanks Jean-Christophe for your response!

So, when I have a view that has a @Route annotation, without any other annotations it’s basically a spring prototype. That means if I have other components and I would like to inject those in the constructor of that view, those components should at least have @Scope(“prototype”).

I think I’m overusing Spring a bit, I’m basically turning the whole component hierarchy for a view into Spring components.

If it doesn’t have a dependency to some service or a class like a presenter or a need to preserve the same instance for a particular reason, then why not simply use new … right?


You can definitely inject a spring bean in class annotated with @Route . The injected bean can be a prototype ( like a dialog) or a singleton ( like your service.
I’m trying to avoid to turn everything to a spring bean, especially if you don’t need it

1 Like