Implementing Data Repositories

DZone 's Guide to

Implementing Data Repositories

Learn more about how to implement data repositories with Vaadin 8.

· Java Zone ·
Free Resource

This is an excerpt from my book Data-Centric Applications with Vaadin 8.

A repository, for the purposes of this book, is a class that includes all or some of the CRUD operations (Create, Read, Update, and Delete). Repositories encapsulate persistence details in an application. A repository holds the means to the domain model (or entities).

More precisely, a domain model includes not only data but also behavior. Another term used widely is data transfer object (DTO). Although the original definition of DTO was intended to describe a way to transport data between processes, many architectures (inaccurately) define DTO as an object that carries data between software components in the same process. To complicate things even more, there are value objects (objects that are equal if their properties are equal) and entities (objects that are equal based on their identity, which can be defined by a single property). When documenting and designing your software, spend some time investigating the terms and try to choose the one that best matches your design.

Defining a Domain Model

Let's study this with an example. Suppose you are implementing a simple e-commerce application. You are in charge of the orders module, and have to provide access to the data related to this module through a web UI. After reading the specification, you designed a simple domain model formed by the following classes:

Image title

This is pretty straightforward: an Order has one or more Product objects and one Customer . You want to use the hypothetical Technology X to persist data (it doesn't matter which one for this example), and you want your Vaadin UI implementation to be able to directly use the domain class; however, you don't want to couple your UI implementation with Technology X. Moreover, you have to expose orders and product data through a web service for an external accounting system. You decided, then, to implement three repositories, one for each domain class: ProductRepository , OrderRepository , and CustomerRepository .

Implementing Repositories and Services

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:

Image title

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.

The previous hypothetical example doesn't imply that you shouldn't enforce a repository/service pairing kind of design in your projects. Always stop and think before making this kind of decision. The situation in the example shows how the developers considered alternatives, investigated the requirements more deeply, and then took an informed decision. Keep the developers, who will maintain your code in the future in mind. Keep your legacy in mind.

The Active Record Pattern

There are many architectural patterns that may or may not help in your projects, in particular, regarding domain models and persistence. You might want to have a look at the active record pattern. An active record class encapsulates not only the data but also its persistence operations. For example, the Order class of the previous example would look like the following:

Image title

Notice how the CRUD operations are implemented in the domain class alongside with the methods previously implemented in the repository class. Although being an alternative to keep in mind, we won't further cover or use the active record pattern in this book.

This was an excerpt from my book Data-Centric Applications with Vaadin 8. You can buy it on amazon.com, packtpub.com, and many other online bookstores.

data ,data access ,data access layer ,database abstraction layer ,database access ,java ,vaadin ,vaadin framework 8

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}