数据访问层组件设计以及选型意识流 第四次扩展的讨论

接上篇。。。

 

前面提到，我们的组件有以下五个点目前没有支持：

 

1. 对列表属性的级联操作（这个没技术含量，随时可以加上）

2.自动生成查询语句的时候不支持OR， 我坚决认为支持OR是违反原则的，OR代表了业务逻辑，并且OR查询放在数据库还是换成在内存中的UNION还稍微降低了数据库的的工作量，也不大幅提升网络传输量（JOIN和GROUP BY虽然也稍微降低了数据库的工作量，但却可能大幅提升了网络传输量）

3.自动生成查询语句的时候，不支持在SQL上直接对数据库列进行任何计算，  我坚决认为在SQL中做运算是可耻的行为，运算代表了业务逻辑！

4. 对自动生成JOIN的支持，为了降低网络传输量

5. 对自动生成GROUP BY以及HAVING的支持，为了降低网络传输量

 

 

现在就让我们对4和5进行一些分析和讨论吧。

 

 

首先，要支持JOIN， 要解决如下问题：

 

1.自动给参与JOIN的实体对应的表设置一个别名（以实体的类名作为表别名不行的，因为可能是同一个表JOIN自己），这个好解决

2.要把ON 条件带过来，ON 条件可能有多个

3.解决两个以上的表的JOIN问题

4.当多个表JOIN时，重复字段怎么处理

5. JOIN后的结果集，我们要单独创建一个实体来映射吗？

     如果是，就违反了领域设计的原则了。

     如果不是，那么我们的一个查询就需要返回多种实体（这些实体分别对应参与JOIN 的表，NH就是这么做的），这个需要略微修改之前的代码的吧

          而且，返回的多种实体列表，相互之间没有关联啊， 应为我们没有维护一份表之间的关系，关联不起来（关联起来了也不准确），如果按ON条件进行关联，那当然准确，可是很复杂，想想5个表进行JOIN的情况吧。

 

综上所述，我觉得要支持JOIN ,在代码里要带进去的信息太多,第二条和第四条需要信息,第五条带来了复杂性!

就算实现了.废了九牛二虎之力,做出来的也是鸡肋,开发人员用起来也很繁杂,不爽! 不如直接写SQL（其实JOIN查询本身就是违反原则的，带了业务逻辑去数据库） 。

 

前面我说可以用IN查询去替换JOIN, 如果不这样做，行吗?行！

别忘了我们还有前面第二次封装的接口可以直接使用，虽然是直接写SQL，但是是配置起来的，并且可以直接返回实体，已经很好用了！ 比较一下现有的做法吧,真的算很好用了。

 

 

 

好，接下来，讨论GROUP BY(以及HAVING), 要支持GROUP BY，分析如下：

 

1.如果在支持JOIN 的基础上再支持GROUP BY，简单的做法是在JOIN生成的SQL之外再包装一层查询（但实现JOIN本身就不简单）。

2. 我们要为GROUP BY查询的结果另外创建实体吗？是？违反了领域设计思想；不是？那难道返回DATAREADER?

3.GROUP BY 的聚合操作其实也是业务逻辑的

4. 如果要支持，我们得评估一下要支持哪些聚合函数 （常见的有avg,count,first, last,max,min,sum），我们需要支持（avg,count,max,min,sum），然后需要加上这些表达式解析

 

 

分析完毕，结论：

还是不想支持JOIN(可以支持两个表的JOIN)，但是可以支持GROUP BY，HAVING