Advanced Application Architectures

    Layered architectures, where each layer has a clearly distinct responsibility, are probably the most common architectures. Typically, applications follow at least a three-layer architecture:

    • Domain layer

    • Data store layer

    Such an architecture starts from a domain model, which defines the data model and the “business logic” of the application, typically as beans or POJOs. A user interface is built on top of the domain model, in our context with the Vaadin Framework. The Vaadin user interface could be bound directly to the data model through the Vaadin Data Model, described in “Binding Components to Data”. Beneath the domain model lies a data store, such as a relational database. The dependencies between the layers are restricted so that a higher layer may depend on a lower one, but never the other way around.

    Three-layer architecture

    An application layer (or service layer) is often distinguished from the domain layer, offering the domain logic as a service, which can be used by the user interface layer, as well as for other uses. In Java EE development, Enterprise JavaBeans (EJBs) are typically used for building this layer.

    Model-View-Presenter Pattern

    The Model-View-Presenter (MVP) pattern is one of the most common patterns in developing large applications with Vaadin. It is similar to the older Model-View-Controller (MVC) pattern, which is not as meaningful in Vaadin development. Instead of an implementation-aware controller, there is an implementation-agnostic presenter that operates the view through an interface. The view does not interact directly with the model. This isolates the view implementation better than in MVC and allows easier unit testing of the presenter and model.

    mvp pattern hi

    Model-View-Presenter pattern

    Model-View-Presenter pattern illustrates the MVP pattern with a simple calculator. The domain model is realized in the Calculator class, which includes a data model and some model logic operations. The CalculatorViewImpl is a Vaadin implementation of the view, defined in the CalculatorView interface. The CalculatorPresenter handles the user interface logic. User interaction events received in the view are translated into implementation-independent events for the presenter to handle (the view implementation could also just call the presenter).

    Let us first look how the model and view are bound together by the presenter in the following example:

    Java

    You could add the view anywhere in a Vaadin application, as it is a composite component.

    Our business model is quite simple, with one value and a number of operations for manipulating it.

    The purpose of the view in MVP is to display data and receive user interaction. It relays the user interaction to the presenter in an fashion that is independent of the view implementation, that is, no Vaadin events. It is defined as a UI framework interface that can have multiple implementations.

    Java

    The are design alternatives for the view. It could receive the listener in its constructor, or it could just know the presenter. Here, we forward button clicks as an implementation-independent event.

    As we are using Vaadin, we make a Vaadin implementation of the interface as follows:

    Java

    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. It shows data in the view and receives user interaction back from it.

    Java

    In the above example, we held some state information in the presenter. Alternatively, we could have had an intermediate controller between the presenter and the model to handle the low-level button logic.