When I started to develop with vaadin, before the version 7 came out, there were no documentation about which pattern suits better for vaadin development. For having little experience in web application development and only knowing one pattern, I started developing an application using MVC.
After sometime, I noticed that somethings in vaadin doesn’t fit on the MVC pattern. It’s like the “View” and “Controller”, in the MVC point of view, are really attached to each other in the vaadin framework.
1 year later, I saw a blog post about the MVP pattern and how the framework is based on this pattern. But there are so few examples and is so verbose, that I don’t think it is actually the best approach for big applications.
Please, I’ve been researching for a week, and can’t seem to find some light in this.
Unfortunately, the documentation on architectural patterns is rather thin. In the book, there’s the
basic UI design section and the
somewhat stub architecture section . I would like to see deeper articles or presentations from architecture experts. There are some excellent
Vaadin webinars that deal with those topics; some that come to my mind are the ones building
mobile enterprise apps and the
Spring best practices (which is getting a bit outdated with the upcoming Vaadin Spring). Then there’s architecture topics like
using OSGi with Vaadin apps (a bit old – there’s also a more recent webinar).
Vaadin indeed doesn’t exactly fit the MVC model. Vaadin also isn’t based on MVP – the pattern is used in many enterprise application projects with Vaadin (so it is fully usable with Vaadin, but Vaadin is not based on it). Not that MVP is a necessity, but anyhow.
There are no really solid frameworks out there that you can use with vaadin as far as I know (would love to be proved wrong!). There are a few attempts in the add-on directory, but I don’t see many that have been updated recently. But it is still possible to build large-scale apps with it, but with Vaadin the productivity boost comes from the components rather than the framework. Would be great to see more discussion on this and fewer trivial examples of MVP being applied.
Having said that, a lot of people (us included) use a very simple form of MVP to get the job done and it works reasonably well. We just try to keep things simple and take things screen by screen without trying to bring everything together using big framework-y abstractions. We also use the ‘Context Object Locator’ addon extensively:
https://github.com/silb/col-vaadin . This addon allows us to store contextual information in the component hierarchy (e.g. a property containing the id of a selected entity).
These are a few of the limitations of this approach and vaadin that its useful to bear in mind:
Home-brew MVP is fairly easy to implement, but as you’ve already discovered is of limited utility in larger projects. The MVP pattern isn’t that well defined to start with, and has nothing to say about how to compose itself into hierarchies of views, presenters, and models and how this works with Navigation and DI.
Although Vaadin provides an API for observable models in the form of Items and Containers, these APIs are nowhere near as easy to work with as anything like the models in Angular js. These APIs have a long history and are highly depended on within Vaadin, I don’t see them changing any time soon, and it would not be easy to replace them with anything better.
IMO Vaadin lacks a robust Navigation abstraction. The Navigation API is a good start, but it’s not clear at all how to implement hierarchical navigation using it. I’ve made several runs at it and have given up each time. Really the navigation/view-state mechanism needs to be tied into the MVP pattern and DI. Right now these are all totally separate things.
Having said that, I still think Vaadin gives us a big productivity boost because of the quality of the components.
IMO the future of vaadin + frameworks lies in client side development. As the Vaadin team continue to work on their client side APIs for GWT and web-components, Vaadin components will be usable within frameworks written for GWT and javascript/HTML5 where there has been greater momentum in framework development due to larger developer base. This allows Vaadin to concentrate on where it really adds value; in the components. The newly released Grid component has 32k+ lines of code and took over a year to develop. It’s difficult to see how development of something like Grid would be possible without the commercial backing of a company like Vaadin.