DBHub的前世今生

1 为什么会做这个组件

我们开发材料管理系统的时候，有大量的增删改查操作场景，特别是对材料明细量表进行操作的时候，我们遇到了一些问题：

1. 如果用户每输入一行信息就执行一次数据库读写的话，古老的ADO.NET组件执行效率不高；
2. 数据库连接反复开关，而且在多用户并发操作的情况下表出现锁冲突；
3. SQL语句拼接工作量大，完全属于无技术含量的体力劳动；

做这个组件的最主要初衷并不是打算对性能进行革命性的提升，因为用的还是ADO.NET，我最主要的想法是为了偷懒，把拼接sql语句的工作封装起来，用一个标准化的方法来解析和组装sql语句，并直接执行返回结果，我的目标是：

1. 所有的增删改都不再需要写SQL语句；
2. 所有的数据批量增删改操作在一次数据库连接打开关闭内完成；

那个时候.NET虽然有ORM组件，但是在数据批量处理时能力弱，一冲动就自己造了个轮子。

2 组件的设计思路

DBHub的作用是为了方便地将数据集（以下简称dt）批量写入或更新到数据表，这个写入一般就是单纯的insert操作，更新则包括了两个含义，一是数据记录的某些非主键字段值发生了变化，这个是update操作，二是数据记录被删除了，这个是delete操作。现在就要解决一个问题，我们如果用最方便的方式告诉系统所有这些操作的内容。

2.1 下面先定义两个概念：

1. 目标数据集dt：数据库表原始内容或者原始内容的子集完成全部操作后的数据集；
2. 参照系数据集ds：数据库表原始内容或者原始内容的子集；

2.2 使用者要做的事情是：

1. 把数据集按照表结构组装起来，并在内存中处理成目标数据集dt；
2. 查询出参照系数据集ds；
3. 把dt和ds交给DBHub，剩下的事情由DBHub全部搞定（让它帮我们把ds变成dt）。

2.3 设计图

2.4 设计思路：

DBHub的核心思想就是把对SQL的拼接处理改成对DataTable对象的处理，有一点ORM的思想在里面，毕竟DataTable对象也可以理解为就是一个Dto对象，我们根据业务逻辑把dt加工好，使得dt变成最终成品的样子，然后去数据库里取参照系数据集ds，这个ds可能是整张表，也可能是整张表的子集，DBHub负责封装标准的方法，将ds加工成dt的样子。

为什么需要ds的子集，因为ds有可能非常大，DBHub对dt进行加工的时候必不可少需要对参照系ds进行遍历和取值，如果ds超级大，那遍历的速度可想而知，这也就是为什么要设计一个filter参数的原因。

早期.NET的ORM处理批量数据的性能不理想，有一些第三方的数据持久层框架，但是用起来好复杂，于是我下决心自己造了这个土轮子，现在ORM性能已经越来越好，不过DBHub在一些特定场景（同时存在插入、修改和删除操作的大批量数据）表现依然稳定，而且使用Bulk方法，所以数据写入速度非常快（号称百万行数据秒级写入）。

2.5 功能和特性：

1. 将所有对数据表的增删改操作通过对dt的处理一次性更新到数据表；
2. 对主键已经存在的数据可以通过参数开关决定是采用略过或者更新的方式来处理；
3. 可以通过过滤器参数，缩小参照系数据集ds，提升DBHub成员方法内部数据处理的性能；
4. 判断送入的dt与数据表结构是否一致，提示缺少的字段或者多出的字段；
5. 支持多个字段是主键；
6. 判断主键是否一致；

3 规划

未来我想实现对多种主流关系型数据库的适配，使DBHub成为一个通用型组件，但是难度还是非常大的，基本上需要完全重写。前路漫漫，愿我们归来仍是少年。