Introduction

If you mean a Spring Data JPA repository with no entity at all, the short answer is that this is usually the wrong abstraction. A JPA repository is built around an entity type and its identity. If your use case does not have an entity, you usually want a custom repository class, JdbcTemplate, NamedParameterJdbcTemplate, or a query-oriented service that returns DTOs instead.

Why JPA Repositories Expect Entities

A typical Spring Data repository looks like this:

public interface UserRepository extends JpaRepository<User, Long> {
}

The User entity is central to the design. The repository API exists to persist and query aggregate roots or entities, not arbitrary result sets with no domain type behind them.

That is why trying to create JpaRepository<?, ?> with no entity usually means the design should be adjusted rather than hacked around.

Use JdbcTemplate for Query-Only Access

If you need repository-like access to database rows but do not want a JPA entity, JdbcTemplate is usually a better fit.

1import org.springframework.jdbc.core.JdbcTemplate;
2import org.springframework.stereotype.Repository;
3
4import java.util.List;
5
6@Repository
7public class ReportRepository {
8
9    private final JdbcTemplate jdbcTemplate;
10
11    public ReportRepository(JdbcTemplate jdbcTemplate) {
12        this.jdbcTemplate = jdbcTemplate;
13    }
14
15    public List<String> findCustomerNames() {
16        return jdbcTemplate.query(
17            "select name from customers order by name",
18            (rs, rowNum) -> rs.getString("name")
19        );
20    }
21}

This is often exactly what you want when the data is read-only or shaped for reporting rather than for entity lifecycle management.

Use DTOs Instead of Entities

Even without entities, you can still map query results into meaningful types.

public record CustomerSummary(long id, String name, int orderCount) {
}

1public List<CustomerSummary> findCustomerSummaries() {
2    return jdbcTemplate.query(
3        """
4        select c.id, c.name, count(o.id) as order_count
5        from customers c
6        left join orders o on o.customer_id = c.id
7        group by c.id, c.name
8        """,
9        (rs, rowNum) -> new CustomerSummary(
10            rs.getLong("id"),
11            rs.getString("name"),
12            rs.getInt("order_count")
13        )
14    );
15}

This gives you typed data without pretending the result set is a JPA-managed entity.

When a Custom Repository Interface Still Makes Sense

You can still create a repository-style interface for organization, even if it is not a Spring Data generated repository.

For example:

public interface ReportQueries {
    List<CustomerSummary> findCustomerSummaries();
}

Then provide your own implementation class. This keeps the codebase clean without forcing JPA onto a use case that does not fit JPA's model.

When You Actually Do Need an Entity

If the object:

• is persisted over time
• has identity
• participates in updates and relationships

then it probably should be an entity. Trying to avoid an entity in that case often creates a worse design than just modeling it properly.

So the real question is not "how do I make Spring Data ignore entities". It is "is this actually an entity use case or just a query use case".

Common Pitfalls

• Trying to use JpaRepository for a problem that is really just SQL query access.
• Returning raw Object[] values instead of mapping to DTOs.
• Avoiding entities even when the data clearly has identity and lifecycle.
• Calling any data-access class a repository without being clear about whether it is JPA-backed or custom.
• Forcing Spring Data abstractions onto reporting or projection use cases that fit JdbcTemplate better.

Summary

• A JPA repository is normally built around an entity type.
• If you have no entity, use JdbcTemplate, custom repository code, or DTO-focused query classes.
• Custom interfaces are still useful for organization even without Spring Data generation.
• Do not avoid entities when the data really has entity semantics.
• Choose the persistence abstraction based on the shape of the problem, not on repository naming alone.