Bean Searcher vs MyBatis Plus: Which Dynamic Query Tool Wins?

Bean Searcher claims to handle any complex query with a single line of code, while MyBatis Plus also provides dynamic query capabilities; this article compares their differences.

Difference 1 (Basic)

MyBatis Plus depends on MyBatis and provides full CRUD functionality, whereas Bean Searcher does not depend on any ORM and focuses solely on advanced queries.

Only projects that use MyBatis can use MyBatis Plus; projects using Hibernate, Spring Data JDBC, etc., cannot, but all of them can use Bean Searcher, which works with any ORM or standalone.

MyBatis Plus requires an entity class and a Mapper interface, while Bean Searcher only needs an entity class.

This distinction is minor because MyBatis Plus still requires a Mapper for insert, update, and delete operations.

Difference 2 (Advanced Query)

MyBatis Plus uses static field operators, while Bean Searcher uses dynamic ones.

Field operators such as = , > , like are static in most traditional ORMs, including MyBatis Plus, Hibernate, Spring Data JDBC, JOOQ, etc.

Example with a simple entity class:

public class User {
    private long id;
    private String name;
    private int age;
    // getters and setters omitted
}

1) MyBatis Plus query

Dependency:

implementation 'com.baomidou:mybatis-plus-boot-starter:3.5.2'

Mapper interface:

public interface UserMapper extends BaseMapper<User> {}

Controller method:

@RestController
@RequestMapping("/user")
public class UserController {
    @Autowired
    private UserMapper userMapper;

    @GetMapping("/mp")
    public List<User> mp(User user) {
        return userMapper.selectList(new QueryWrapper<>(user));
    }
}

This endpoint supports three parameters (id, name, age) with equality checks only. To query age > 20, a custom annotation on the entity field is required, which then restricts the field to only the greater‑than operator.

Although you could switch operators in the controller, the code would no longer be a single line.

2) Bean Searcher query

Dependency:

implementation 'cn.zhxu:bean-searcher-boot-starter:4.1.2'

No interface is needed; the same entity class is reused:

@RestController
@RequestMapping("/user")
public class UserController {
    @Autowired
    private BeanSearcher beanSearcher;

    @GetMapping("/bs")
    public List<User> bs(@RequestParam Map<String, Object> params) {
        return beanSearcher.searchList(User.class, params);
    }
}

This endpoint can handle many more parameters, such as case‑insensitive matching, contains, greater‑than, etc., by using the xxx‑op suffix.

All field operators are dynamic and can be specified by request parameters.

Difference 3 (Logical Grouping)

MyBatis Plus generates only AND conditions from parameters, while Bean Searcher also supports logical grouping.

Example condition: (name = Jack AND age = 20) OR (age = 30). Bean Searcher can express this with grouped parameters a and b and a gexpr expression like a|b (URL‑encoded as a%7Cb).

Difference 4 (Multi‑Table Join)

MyBatis Plus dynamic queries are limited to single tables; Bean Searcher supports both single‑table and multi‑table queries without writing SQL.

Example VO for an order list with three tables:

@SearchBean(
    tables = "order o, shop s, user u",
    where = "o.shop_id = s.id and o.buyer_id = u.id",
    autoMapTo = "o"
)
public class OrderVO {
    private long id; // o.id
    private String orderNo; // o.order_no
    private long amount; // o.amount
    @DbField("s.name")
    private String shop; // s.name
    @DbField("u.name")
    private String buyer; // u.name
    // getters and setters omitted
}

Controller method (still a single line):

@RestController
@RequestMapping("/order")
public class OrderController {
    @Autowired
    private BeanSearcher beanSearcher;

    @GetMapping("/index")
    public SearchResult<OrderVO> index(@RequestParam Map<String, Object> params) {
        return beanSearcher.search(OrderVO.class, params);
    }
}

Difference 5 (Use Cases)

Transactional interfaces are recommended to use MyBatis Plus; non‑transactional retrieval interfaces are recommended to use Bean Searcher.

Creating an order may involve many checks (shop status, stock) – use MyBatis Plus or other ORM.

Order list pagination, sorting, filtering – use Bean Searcher.

FAQ

1) Is the extensive query capability risky?

Bean Searcher allows many operators per field by default, but you can constrain them with annotations such as @DbField(onlyOn = {Equal.class, StartWith.class}) or disable a field entirely with @DbField(conditional = false).

2) Must the controller parameter be a Map ?

No. You can accept a POJO, then convert it to a map with a utility method before passing it to Bean Searcher.

3) Can I manually add or modify parameters?

Yes, Bean Searcher provides a parameter builder to augment or change parameters fluently.

4) Is there a SQL‑injection risk?

No. Bean Searcher is a read‑only ORM; parameters are mapped to Java property names, and unknown fields are ignored, keeping queries safe.

5) Can users retrieve data they shouldn't see by passing arbitrary parameters?

No. Adding parameters only narrows the result set; the widest query is the parameter‑less request.

6) Performance comparison

5‑10× faster than Spring Data JDBC

2‑3× faster than Spring Data JPA

1‑2× faster than native MyBatis

2‑5× faster than MyBatis Plus

Tests were performed on an H2 in‑memory database; source code is available on GitHub and Gitee.

7) Which databases are supported?

Any database with standard SQL syntax is supported. Bean Searcher provides dialects for MySQL‑style, PostgreSQL‑style, Oracle‑style, and SQL Server‑style pagination.

Conclusion

The differences outlined above show that MyBatis Plus and Bean Searcher focus on different domains: MyBatis Plus excels in transactional operations, while Bean Searcher shines in advanced, especially multi‑table, read‑only queries. Using them together—MyBatis Plus for transactional logic and Bean Searcher for list retrieval—gives a powerful, concise backend solution.