Search code examples
springjsfdependenciesspring-datan-tier-architecture

Should I create a dependency from presentation tier to Spring Data to use pagination


We are creating a web based application using, JSF (Primefaces as presentation library) and Spring Data JPA for data access tier. And the project is Spring Boot enabled.

The project is divided into multiple modules (according to tiers), and one of them is the presentation tier.

Do you suggest creating a dependency from presentation tier to Spring Data (so have access to PageRequest and Slice and ... classes) or not?

Otherwise we shall re-implement these classes in this tier and convert them to Spring Data classes, which seems some how verbose.


Solution

  • Do you suggest creating a dependency from presentation tier to Spring Data (so have access to PageRequest and Slice and ... classes) or not?

    Every decision you make will have it's Pros and Cons and it really depends on your specific situation if this is a problem or not.

    I see the following things in favor of a dependency:

    • reuse of PageRequest and similar classes. They represent concepts that are needed when working with persistence but aren't really persistence specific. Therefore there is really no point in duplicating them.

    On the other hand, Spring Data contains many classes that don't have any business in a presentation layer. For example, those dealing with creating repositories.

    Your task is to determine if the risk/damage of having those classes around is bigger than the benefit of having PageRequest and co available.

    With all teams and projects I worked with so far I'd opt for just having a dependency.

    Here is why:

    1. The domain has a dependency on JPA and Spring Data anyway. So by depending on the domain-layer, you get a transient dependency, no matter if you want or not.

    2. The persistence specific classes inside Spring Data are so specific that I never experienced anybody trying to use them directly.

    Note that especially the first point assumes that you are not copying over your JPA entities in separate transport objects, which would kind of negate the benefits of JPA.