At this point, you started implementing the Vaadin UI, and had a clear understanding of the methods that the repositories should expose. You then implemented these methods in the respective repository classes:

Let's take a closer look at the methods in the repository classes. As you can see, all method names start with find or get. This is a well-known convention in the industry, and it's used by libraries such as Spring Data or Apache DeltaSpike. Methods starting with find return a collection of objects, while methods starting with get return single, ready-to-use values (such as a domain instance, or one of its properties).

Notice how each repository has a private persistence field that represents the entry point to use Technology X, we will see concrete examples of this later in this chapter. If, for some reason, you had to change the persistence technology to something else, client classes wouldn't be affected. Moreover, you can use different persistence technologies for different repositories without having client classes to deal with different APIs. The following code will give you a clear idea of how these repositories can be implemented:

public class OrderRepository {

    private TechnologyX persistence = ...

    public List<Product> findAll() {
        ... use Technology X through the persistence instance to fetch the data ...
        ... convert the data to a List ...
        return list;
    }
    ...
}

All the implementation details regarding how to get the data are encapsulated in the repository class. Now, let's move on and see how this can be used from a Vaadin application.

While doing pair programming, your colleague suggested you should use service classes to abstract away the concept of repository from the Vaadin UI. She argued that there should be one service class for each repository: ProductService, OrderService, and CustomerService. It seemed like a good idea to you too; however, she immediately noticed that the service classes would be simple facades for their repository counterparts, and wouldn't include any extra logic. You pointed out that the application had to expose data through a web service consumed by the accounting system, and that the service classes might be used for that. After you and your colleague investigated the precise data the web service had to expose, you both decided to Fight for Simplicity, and not to implement one service class per repository class.

Instead, the Vaadin UI would be allowed to have references to the repository classes. You also decided to implement a separate AccountingWebService class to expose the data for the accounting system, so that you could know and control what this system is "seeing" in the future. As with the Vaadin UI classes, the web service implementation would use the repository classes to fetch data.