Some summaries of ibatis script and provider

Preface

Since I first used annotation based Dao Layer framework iBatis Since then, I have been fascinated by the design sense and use experience of this minimalist cold wind .
But as the saying goes , Fate has already marked the price of every gift , We should draw a list in the future . When developing complex dynamics SQL when ,iBatis It's not easy to use . Today is a brief summary iBatis Use , And the analysis of advantages and disadvantages , And talk about some of my solutions .

Start with a query

@Select("select * from user where name like #{name}")
List<UserEntity> getAllUser(SearchUserVo searchUserVo);

This is a very common ibatis Inquire about , The framework will put #{name} Replace with searchUserVo The value of the corresponding field in .
If our inquiry is limited to this , Then everything will be perfect , however ：

Complexity 01

If name by Null Well ？ What if there are other conditions ？ These conditions may also be Null Well ？
This requires dynamic SQL 了 . here ,script The script comes on stage , The above code is rewritten as ：

@Select(
"<script>"
+ "select * from user "
+ "<where>"
+ " 1 = 1 "
+ "<if test='name!=null'>"
+ " and name like #{name}"
+ "</if>"
+ "<if test='address != null'>"
+ " and address=#{address} "
+ "</if>"
+ "</where>"
+ " limit #{page}, #{size} "
+ "</script>")
List<UserEntity> getAllUser(SearchUserVo searchUserVo);

This achieves dynamic SQL The requirements of .
But the problem is more than that , If name,address Different queries should be made according to different values ？if test=’' The form of is obviously not enough .

Complexity 002

Because we need to make different for the fields to be queried SQL sentence ,@SelectProvider The debut . This query needs to be split into two parts , One is @SelectProvider Definition SQL Provide classes and methods , The second is specific SQL Provide classes and methods ：

1. @SelectProvider How to write it

@SelectProvider(type = UserProvider.class, method = "allUserMethod")
List<UserEntity> getAllUser(SearchUserVo searchUserVo);

2. Class and corresponding method ：

public class UserProvider{
    

	public String allUserMethod(SearchUserVo searchUserVo) {
    
		StringBuilder sql = new StringBuilder();
		sql.append("select * from user where 1=1 ");
		if(StringUtils.hasText(searchUserVo.getName())) {
    
			if("wang".equals(searchUserVo.getName())) {
    
				sql.append(" and name=").append(searchUserVo.getName()).append(" ");
			} else {
    
				sql.append(" and name like ").append(searchUserVo.getName())
			}.append(" ");
		}

		return sql.toString();
	}
}

It can be seen that this kind of writing is quite good , Simple and effective , To meet the requirements .
But it has a fatal problem , It just can't be reversed SQL Inject .

Complexity 003

therefore , Further introduce standardization SQL Generate interface ：

public String allUserMethod(SearchUserVo searchUserVo) {
    
	return new SQL(){
    {
    
        }}.toString();
}

This thing is quite easy to use , Interested students can check the usage here ： Standardization SQL Generation scheme

The only problem is …
Here we are ,ibatis Annotate all the usability of interface development 、 Minimalism is gone , It's the same thing Jpa,Xml turn Mybatis, even to the extent that template What's the difference? Fall ！

summary

iBatis It does have its uniqueness in design , Simple and elegant , memorable , Addictive with it . But with the complexity of the problem , Its development complexity will also rise rapidly , Until it is almost close to the old frames . So which one is used in the project DAO frame , It still depends on the specific needs of the project , Don't superstitious about a certain technology .
Go to have afternoon tea ,88