2016年我们完成.net工作流重写后，客户群转向了集团级企业。在推广过程中，业主单位不断给我们的产品提出多数据库支持需求。因为业主方不想对数据库中间件过多的投入，希望在他们现有的资源基础上构建。非常遗憾，我们当时的产品是.net+C#+sqlserver系列。
2020年，由于种种原因，我们技术转向了java方向。对多数据库版本的支持优先进入了我们的考虑范围。为此，我们在不断验证者对多数据源支持方案。
优先需要支持的有：sqlserver、oracle、mysql,postgresql等数据库。
怎么找到一个适合我们的数据库操作标准构建是我们优先考虑的问题。最终在我们产品中落地的有：mybatis/mybatis-plugs。
2.Mybatis标准件构建的需求如果我们不进行多数据库版本支持，JDBCTemplate在spring 生态中是一个不错的选择。但如果必须支持多数据库，那就必须重新进行选择或构建了。
数据库的操作主要是增/删/改/查/模型查询与修改等。数据库的核心职责是数据的存储与查询，那我们对多数据库支持有什么需求呢？
- 随着产品的推广，业主方的数据库多样性会不断丰富。这要求我们在不过度设计的基础上能向后支持，如不断出现的国产数据库等。这要求我们能在不修改原有代码的基础上，完成相应数据库操作的适配。查询数据时，希望数据库操作主键能直接根据业务需要返回对应的结果：如特定模型对象/特定模型列表/map集合等。对数据操作时（新增/修改/删除）能直接接收输入模型对象作为参数。由于ER模型都时基于对象进行，希望相关的sql能在后续不断进行完善，而不需要调整太多的内容。对于sql语言，能否提供更简单的模式提供标准的字符串拼接能力。其他
Mybatis标准件是面向多数库的数据ER组件，基本能满足业务需求。
3.Mybatis设计梳理ER模型核心是需要完数据库字段与模型对象的映射。在Mybatis中，采用了数据类型处理器与数据类型注册对象来规范化描述数据库字段与内存模型字段的转换处理器，并基于java中的反射机制完成了内存对象与数据库字段直接的映射关系。
为了方法sql语句的描述，采用了java注解来描述增/删/改/查语句。
为了sql语句面向未来实现，引入了xml配置文件来描述sql语言，同时提供了sql语句提供者对象。可以完成不同数据库的不断扩展需求.
在xml配置文件中，引入了基于模型验证的标签，使sql语句的动态拼接更为工序化，降低手写sql的风险等。
4.其他
