标签:表格 成员 sim 方法 自增 原因 ida factory cat
目录
simple-orm-mybatis在github开源,直接跳转查看,欢迎大家fork和star。有什么建议也可以提出,我会尽快修复或实现。
最早接触Java的web开发框架就是SSH,其中的H就是Hibernate。Hibernate作为最出名的Java的ORM框架,现在的版本已经到了5.3.10.Final,6.0.0.Alpha2。围绕数据持久化或者DAL层也发展了多种工具,Hibernate Validator目前也是在很多的企业框架中被用作数据有效性检查。
接下来还有用过JPA来实现ORM。JPA全称Java Persistence API,是JSR-220(EJB3.0)规范的一部分,在JSR-220中规定实体对象(EntityBean)由JPA进行支持。在我的使用中,实际上底层实现仍然使用了Hibernate,只是标注或者操作类都是使用了JPA的接口标准而没有直接使用Hibernate。
Hibernate具有强大的ORM封装能力,极大的简化了CUD的操作,而且无需做太多的配置,使用标准注解就能解决很多问题。简单的查询操作也不在话下,多级关联、延迟查询等丰富特性基本上也可以说是极大覆盖了开发过程的各种需求。但是实际上在这么多团队中,很多人的反馈是这样的:“Hibernate的ORM确实很方便,但是在一些特殊条件下很难用,比如复杂查询就很难控制语句生成的效率”。Hibernate有三种查询方式:HQL、Criteria、Native Sql。确实在复杂查询下,如果使用Criteria,确实能够拼出想要的语句,但是可能对于其中的方法要非常熟悉,学习曲线很高,没办法做到团队中每个成员都能数量轻易的掌握,而且后期的审核很困难无法直接看清逻辑。HQL和NativeSql对我的感觉,似乎回到了JSP时代,HTML和Java代码混写,很难忍受。这时候大家找到了另外的框架Mybatis。
截止(2019/5/27)Mybatis的Star是10806,UsedBy140381;Hibernate的Star是3817,UsedBy157879。看使用量Hibernate和Mybatis其实已经差不多了,实际企业开发中,Mybatis可能还会更多一些。
Mybatis放弃了Hibernate的强封装,主要包含了映射的部分,而且放弃了自动解析生成Sql,而直接使用用户XML配置Sql的方式,只是在Sql的拼接上提供了一些标签来避免重复代码。这样的讨巧之处在于:
缺点也有几处:
实际上,针对上面缺点,Mybatis也提供了解决方案。
先说sql id的,在新的Mybatis中,实际上已经采用了面向接口的编码方式,如下面的例子:
接口类
public interface UserMapper {
public User findUserById(Integer id);
}
mapper的xml文件
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE mapper PUBLIC "-//mybatis.org//DTD Mapper 3.0//EN" "http://mybatis.org/dtd/mybatis-3-mapper.dtd" >
<mapper namespace="com.software5000.mapper.dao.UserMapper">
<select id="findUserById" resultType="com.software5000.entity.User" parameterType="int" >
select * from user where id =#{id}
</select>
</mapper>
这样就可以直接调用sql语句:
UserMapper userMapper = sqlSession.getMapper(UserMapper.class);
User user = userMapper.findUserById(1);
再说映射复杂的,Mybatis提供了MyBatis Generator作为解决方案,一个命令生成下列内容:
自动生成也能够合理的生成类之间的继承关系。注意生成器也能够定义生产不同的POJO层次 - 例如如果你想要可以为每个表格生成一个单独的领域对象。
生成的SQL语句取决于表格的结构(例如,表格如果没有主键,就不会生成按主键更新的方法)
Java客户端生成类能够合理使用上面的对象。生成的Java客户端类也是有选择性的。
但是,我对于MyBatis Generator的态度是坚定的反对。原因是我认为自动生成违反了简单的原则,“如无必要,勿增实体”。自动生成的可复用性和可读性一定是比较差的。我觉得最好的代码就是不存在的代码。因此我希望能够有一个简单框架在Mybatis之上,接入简单无侵入,能够提供基本的增删改查方法。这就是下面的 simple-orm-mybatis 。
simple-orm-mybatis设计的初衷就是希望提供一个简单无侵入,而且无需编写或者生成任何代码就可以使用直接操作对象的方式来进行增删改查的操作。要实现这样的要求,主要是两个主要技术点:
第一点核心就是反射,设计要点如下:
第二点核心在于SQL解析,设计要点如下:
<dependency>
<groupId>com.software5000</groupId>
<artifactId>simple-orm-mybatis</artifactId>
<version>1.0.2</version>
</dependency>
接着需要将 BaseDaoMapper.xml
文件放在你的 mapper 的扫描文件夹内。
import com.software5000.base.BaseDao;
import org.apache.ibatis.session.SqlSession;
import org.apache.ibatis.session.SqlSessionFactory;
import org.mybatis.spring.SqlSessionTemplate;
import org.springframework.stereotype.Component;
import javax.annotation.Resource;
/**
* 整个类以 <code>org.mybatis:mybatis-spring:2.0.0</code> 的 <code>org.mybatis.spring.supportSqlSessionDaoSupport</code>
* 为参考编写而成
*/
@Component
public class MyBaseDao extends BaseDao {
private SqlSessionTemplate sqlSessionTemplate;
public MyBaseDao() {
// 在默认构造函数中设置 数据库是否蛇形, 数据库格式大小写, 通用忽略的字段名称
this.initConfig(true,false,"serialVersionUID");
}
@Resource
public void setSqlSessionFactory(SqlSessionFactory sqlSessionFactory) {
if (this.sqlSessionTemplate == null || sqlSessionFactory != this.sqlSessionTemplate.getSqlSessionFactory()) {
this.sqlSessionTemplate = this.createSqlSessionTemplate(sqlSessionFactory);
}
}
protected SqlSessionTemplate createSqlSessionTemplate(SqlSessionFactory sqlSessionFactory) {
return new SqlSessionTemplate(sqlSessionFactory);
}
@Override
public SqlSession getSqlSession() {
return this.sqlSessionTemplate;
}
}
这里给了一个单元测试的例子,实际一般是在service层直接使用,无需添加任何代码。
示例中的 DailyRecord
是一个普通实体类,没有任何继承。
// 获取启动类,加载配置,确定装载 Spring 程序的装载方法,它回去寻找 主配置启动类(被 @SpringBootApplication 注解的)
@SpringBootTest
// 让 JUnit 运行 Spring 的测试环境, 获得 Spring 环境的上下文的支持
@RunWith(SpringRunner.class)
public class BaseDaoTest {
@Autowired
private MyBaseDao myBaseDao;
@Test
public void testBaseDao(){
DailyRecord dailyRecord = new DailyRecord();
List<DailyRecord> dailyRecords = myBaseDao.selectEntity(dailyRecord);
System.out.println(dailyRecords.size());
}
}
虽说整体的设计基于无侵入,基本没有任何前提,但是还是有一些推荐的实践希望大家能够去尝试:
1、 数据结构设计建议包含int类型的自增主键设计,名称叫id。
原因:很多时候我们的业务主键是有一套特定规则,但是很有可能面对修改,所以底层关联主键统一使用id关联在后期面对修改时影响较小。
弊端:
1. 如mysql中int最长2147483647,考虑到自增id可能会有跳过不连续的情况,需要考虑实际可用的存储量。不过大部分的业务表是到不了这个数量级的。
2. mysql的InnoDB有自增主键锁表的问题,超大并发插入可能会影响效率。不过在5.1.22有提供了改进的策略。
2、 数据结构与实体结构尽量符合统一转换规则。
原因:这样研发过程中,实体与数据库的映射会比较简单,无需大量的自定义。建议的规则有三类:
- 两边都使用驼峰。
- 实体使用驼峰,数据库使用全小写蛇形
- 实体使用驼峰,数据库使用全大写蛇形
3、 代码中实体的字段类型使用封装类型而不是基本类型
原因:基本类型是有默认值存在,而数据库中我们一旦设置字段可空,就会有NULL值存在。所以建议全部使用封装类型。下面附上各种基本类型的默认值
基本类型 | 默认值 |
---|---|
byte | 0 |
short | 0 |
int | 0 |
long | 0L |
float | 0.0f |
double | 0.0d |
char | ‘\u0000’ |
boolean | false |
4、 分页算法
原因:分页推荐使用PageHelper,是利用Mybatis的底层插件机制修改Sql语句,也是无侵入。
更多说明,可以参考github上的wiki页面
[simple-orm-mybaits]基于Mybatis的ORM封装介绍
标签:表格 成员 sim 方法 自增 原因 ida factory cat
原文地址:https://www.cnblogs.com/pluto4596/p/11086970.html