Is Unified ORM Worth It? A Deep Dive into dbVisitor, Jimmer, and JdbcClient

More Uniform, More Complex

dbVisitor aims to provide a single API for MySQL, MongoDB, Elasticsearch, and Redis, eliminating the distinction between ORM and client libraries. While the idea sounds appealing, the added abstraction incurs costs: special queries (e.g., Elasticsearch aggregations) or Redis atomic operations often require "unwrap" mechanisms to reach the underlying driver, reducing the benefit of uniformity.

"When the unified API cannot satisfy special needs, dbVisitor allows an unwrap mechanism to penetrate the underlying driver."

Thus, the promised "one API for any database" is effectively a discounted version of uniform access—simple cases are covered, but complex scenarios revert to low‑level code.

Another Path: Perfecting the ORM

Jimmer, a newer JVM ORM, takes a different route: instead of unifying all data sources, it focuses on making relational ORM exceptionally powerful. It eliminates N+1 queries with compile‑time SQL DSL checks, automatically diffs object graphs to update only changed fields, and uses interface‑based entity definitions generated at compile time.

// Jimmer query example: compile‑time type safety
List<Book> books = sqlClient
    .createQuery(table)
    .where(table.name().like("Java%"))
    .select(
        table.fetch(
            Fetchers.BOOK_FETCHER
                .allScalarFields()
                .store(Fetchers.BOOK_STORE_FETCHER.name())
        )
    )
    .execute();

The trade‑off is a brand‑new DSL, annotations, and mental model that require a learning curve before the benefits are realized.

How Long Can ORM’s Old Tricks Last?

ORMs still provide real value in engineering contexts: a unified API eases team collaboration, enforces consistent code style, and abstracts transaction management, connection pooling, and caching. Historically these advantages justified the extra layer.

However, as AI tools generate perfectly formatted SQL, the ORM’s complex mapping layer becomes an unnecessary middleman. In practice, most projects never switch databases; the cost of maintaining ORM abstractions for a hypothetical heterogeneous‑DB scenario may outweigh the benefits.

Furthermore, concerns such as transaction handling and connection pooling are independent of ORM choice—Spring’s @Transactional works equally well with plain JdbcClient.

JdbcClient: Lightness Is King

Spring’s JdbcClient represents a "subtraction" approach to data access: it is not an ORM nor a full framework, just a concise JDBC wrapper. Compared with MyBatis:

// MyBatis style: define Mapper interface + XML or annotations
@Mapper
public interface UserMapper {
    @Select("SELECT * FROM sys_user WHERE username = #{username}")
    SysUser findByUsername(String username);
}
// Usage
SysUser user = userMapper.findByUsername("lengleng");

// JdbcClient style: one‑liner
SysUser user = jdbcClient
    .sql("SELECT * FROM sys_user WHERE username = :username")
    .param("username", "lengleng")
    .query(SysUser.class)
    .optional()
    .orElse(null);

JdbcClient eliminates the need for separate mapper files, keeps SQL close to the call site, and works seamlessly with AI‑generated queries that can be pasted directly into the code.

In AI‑assisted development scenarios, this lightweight approach reduces friction: the AI writes native SQL, developers plug it into JdbcClient, and avoid the extra step of moving SQL into XML or mapper interfaces.

In the AI era, the best ORM is no ORM at all; the best code is code you don’t have to write.