But what was really confusing me was this sentence:
The presenter in MVP is a middle-man that handles all user interaction logic, but in an implementation-independent way, so that it doesn’t actually know anything about Vaadin.
I don’t really understand how its possible that the “Presenter doesn’t know anything about Vaadin”. Most of the time the main task of a presenter is retrieving data from the model and preparing it so that it can be bound to GUI-components. In Vaadin-terms that means creating containers, items, properties. So the presenter needs to know about these concepts, e.g. needs to know about the com.vaadin.data.Container interface.
I hope the section isn’t too vague about the concepts. The idea of MVP is exactly that only the View knows about the UI framework technicalities. Typically, you could have a view implementation that uses Vaadin and then a GUI-less test view for running unit tests to test the presenter/model logic.
You could also have a view implementation with entirely other UI framework, such as Swing. For example, if you look
this Swing MVP example , you could make that a Vaadin app simply by replacing the View class with a Vaadin implementation (and the main() and such of course). (The example doesn’t define a view interface though.)
Regarding Vaadin containers, it gets more complicated, as containers can be bound directly to the data model. Therefore, if you really make a strict MVP application, you can’t use a Vaadin container that would be directly bound to the data source, such as a JPAContainer or SQLContainer. That would be the case if you had view implementations with completely different UI frameworks and want to use their native data models for data binding. On the other hand, for the more typical use case of MVP with Vaadin, where the other implementation is a unit test, you could be less strict and use Vaadin containers for data binding.
Thanks for your answer. I think the MVP-Section in the book gives a very good introduction! I was just confused about this one sentence.
I was actually planning to avoid JPAContainer/SQLContainer because of the very reason that they are incompatible with my architectural ideas.
But I was planning on using BeanItemContainer.
What would be the proposed way to bind a collections of beans (retrieved from persistency) to a BeanItemContainer in a Vaadin-MVP-Application? Who is responsible for that if not the Presenter?
In my understanding in a strict MVP application with exchangeable views I wouldn’t be able to use any of Vaadin’s data binding features.
Hello Michael,
if you like to save time in writing view and presenter classes, you can use the vaadinator as code generator. Only writing the entity / bean code and add some annotation to the properties and the rest of the work is done by vaadinator.
