Elegant Solution for MyBatis Single‑Table Operations with MyBatis‑Pro Framework

The MyBatis‑Pro framework provides an elegant, convention‑based approach to single‑table operations in MyBatis, aiming to replace handwritten SQL with automatically generated queries that rival JPA in simplicity.

Source code is hosted on GitHub ( https://github.com/Dreamroute/mybatis-pro ) and Gitee ( https://gitee.com/Dreamroute/mybatis-pro ).

Purpose : make single‑table queries graceful, avoid repetitive SQL, achieve JPA‑like advantages, and offer a definitive choice for developers who prefer a minimalist solution.

Quick start : add the starter dependency to a Spring Boot project:

<dependency>
<groupId>com.github.dreamroute</groupId>
<artifactId>mybatis-pro-boot-starter</artifactId>
<version>latest</version>
</dependency>

Defining an entity (example User ) uses annotations to map table and primary key:

@Data
@Table("smart_user")
public class User {
@Id
private Long id;
private String name;
private String password;
private Long version;
}

Mapper interface extends BaseMapper<User, Long> and can declare methods without XML or explicit @Select annotations; the framework generates the SQL automatically:

public interface UserMapper extends BaseMapper<User, Long> {
User findByNameAndPassword(String name, String password);
int countByName(String name);
List<User> findByNameAndPasswordLike(String name, String password, String... cols);
int deleteByNameAndVersion(String name, Long version);
}

Methods prefixed with findBy , countBy , existBy , deleteBy are interpreted by the framework; developers should avoid using these prefixes for custom queries to prevent conflicts.

Framework features include automatic CRUD generation, compatibility with GenericMapper and MyBatis‑Plus, optional enum type handler, generic service layer, logical‑delete plugins (backup or update‑based), pagination support, SQL‑print plugin that replaces placeholders with actual parameters, and optimistic‑lock handling.

Configuration options (application.yml) control enum handling and logical delete behavior:

# Enable built‑in enum type handler
mybatis.pro.enable-enum-type-handler = false
# Enable logical delete
mybatis.pro.enable-logical-delete = false
# Logical delete type (backup or update)
mybatis.pro.logical-delete-type = backup
# Table for backup delete records
mybatis.pro.logical-delete-table = logical_delete
# Column and values for update‑based logical delete
mybatis.pro.logical-delete-column = status
mybatis.pro.logical-delete-active = 1
mybatis.pro.logical-delete-in-active = 0

Built‑in methods provided by BaseMapper cover selection by ID(s), insertion (including null‑exclude and batch), updates, and physical deletions, all of which accept a variable String... cols parameter to specify dynamic column lists.

Entity annotations such as @Table , @Id , @Transient , and @Column define table mapping, primary key, non‑persistent fields, and column aliases respectively.

Special notes explain how empty or null parameters can be ignored by appending Opt to method names (e.g., findByNameAndPasswordOpt ), and how camel‑case to underscore conversion is governed by MyBatis’s map-underscore-to-camel-case setting.

Soul features describe the naming rules that drive query generation: combine property names with And / Or , support for Like , Between , In , IsNull , IsNotBlank , ordering, and descending clauses.

Best practice : use the generic service layer ( BaseService<T, ID> ) and its implementation ( AbstractServiceImpl ) to avoid boilerplate CRUD code, and configure logical delete either by backup table or by status flag update.

Logical delete implementation includes a backup table definition:

CREATE TABLE `logical_delete` (
`id` bigint(20) NOT NULL AUTO_INCREMENT,
`table_name` varchar(100) NOT NULL,
`data` json NOT NULL,
`delete_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=4 DEFAULT CHARSET=utf8;

When the update‑based logical delete is enabled, all generated select and findBy queries automatically append the condition status = 1 (or the configured active value).

Adaptor utilities provide a unified id wrapper for single and batch ID queries and a validator package for comprehensive parameter validation.

Enum handling is achieved via a custom EnumMarker interface and EnumTypeHandler that store enum numeric values in the database while converting them back to enum instances on retrieval. Example enum:

@Getter
@AllArgsConstructor
public enum Gender implements EnumMarker {
MALE(1, "男"), FEMALE(2, "女");
private final Integer value;
private final String desc;
}

When used in an entity, the Gender field is persisted as 1 or 2 and automatically mapped back to the enum.

Authors : 王德海 (author), 吴友强 (reviewer), 周旭龙 (editor).