框架初衷与诞生

这个框架的初衷是，减少Java程序员千篇一律的数据库操作。

对于开发人员来说：

精力应该花费在业务逻辑上，而非机械式的“技术”上。
项目中减少无关痛痒的代码，从抽象的角度看实现。
各司其职，各劳其力，追求项目角度的服务流水线。

# 服务分离的时代

如今已很难看到单体架构的项目（感兴趣的可以查看我对架构演变的描述《浅谈微服务》 (opens new window)），目前的项目大都是通过RESTful、MQ、Socket的方式（协议）进行数据传输。

这让我开始质疑传统JavaWeb项目中的数据库操作模式——即Model(DTO)存在的意义。理论上，数据库设计是不可能完全遵循视图模型的，这就导致“正确”的做法是在项目中引入VO，由多个DTO来组装。

那么，为什么不能用灵活的Map来替代呢？

对一个Map的方法进行拓展，增加其对Json的解析能力，那么是不是就可以摆脱POJO的各种麻烦组装。

# 思考框架设计

我在思考如何设计这个框架的时候，被需要考虑的方方面面给阻挡住了。

因为一个数据库框架需要考虑的东西实在太多了，比如：

事务机制
类型转换
会话管理

···

思来想去，发现自己方向跑偏了，我只是希望统一数据库操作的接口 + 摆脱Model，没必要重新平地起墙，完全可以在一个现有的框架基础上进行封装。

那么，对这个现有框架的选择就尤为重要了。

# 现有框架的选择

目前Java中主流的数据库操作框架：

Spring JDBC
Spring Data JPA
Mybatis
Hibernate

选择现有框架有一个原则——“统一数据库操作的接口 + 摆脱Model”是对该框架的加强，而非变异；不能因为“统一数据库操作的接口 + 摆脱Model”而无法使用原框架的部分功能。

“摆脱Model”这个特点，首先就要排除重度ORM框架，也就是支持JPA操作的数据库——Spring Data JPA、Hibernate；原因很简单，这两个框架的强大之处恰恰就在它完全面向Model操作。

剩下的就只有两个框架了，Spring JDBC和Mybatis。其中，Spring JDBC留给了开发人员大量的可操作空间，更加自由，但恰恰是这种自由使得它更加繁琐。而Mybatis是一个轻量ORM框架，准确来说Mybatis不能称为ORM框架，因为它并不是面向Model操作数据库，仅仅是将数据库字段与Model字段互相赋值，并没有做到ORM定义的关系映射。

# 抉择

由以上各框架的特点，结合国内Java语言中数据库操作框架的热度，毫无疑问的选择了Mybatis。

考虑到SpringBoot对Mybatis优秀的支持级别，我决定基于mybatis-spring-boot-starter开发这款框架，准备来说应该称其为“插件”。

介绍→