Dao和Service的设计方法讨论

liujiuboy:
你大概没有明白gigix先生的意思。
注意他强调的词了么？
对象，接口，声明
使用queryString会不使用参数么？
修改queryString可以像你说的那样，可是如果queryString中参数的顺序变了呢？
service在使用namedQuery的时候，是不是还要去看看queryString里面参数的顺序与类型是什么呢？
这些都需要人工来保证。
为什么我们使用强类型的语言呢？因为接口与声明可以让编译器做许多检查工作。
为什么我们要使用面向对象的语言呢？因为对细节的封装可以使我们隔离变化。
你设计的这个BaseDao其实很像个工具辅助类，而不是数据访问对象。

agentss:
你的思路是关系建模的思路。
如果要充分利用sql的能力，当然首推存储过程。
可是将业务逻辑写入存储过程之中，效率上来了，对于变化的支持能力就降下去了
业务逻辑是不应该表达成一条sql的，应该表达成领域对象之间的交互。
只有关于对象如何保存的逻辑才应该是用数据库的能力
当然，如果是很小的项目，业务层与持久层之间的界限就会比较模糊了

queryString的参数顺序变化根本不会增加更多的复杂性。
因为如果是参数变化，无论是怎么实现的封装得再完美也是非常麻烦的事情。

真正的来说，这个baseDao的问题是，表面看上去非常的light，实际上是异常havy的Dao。

你们难道没有发现？
baseDao.add(obj)这简单的一句话就可能隐藏着后台异常复杂的实现。

如果是hibernate或者是sql，add(Object obj)的实现是不困难的。如果后台是实体Bean呢？不得不用反射来解析这个Obj，而这个Obj还必须附带一些信息来表明该和哪个实体Bean来联系。
这才是真正的复杂性所在。

至于封装我到是觉得是能够隐藏后台细节的。只是一旦改变，这个写Dao的人就痛苦了。

你终于意识到这个问题了？

这句是废话，到底我们要把变化封装在哪儿？难道是service层？


没语言了……

厌倦发呆 :
请问一下，你是如何进行这样的封装的？

你指的是封装queryString呢？
还是DAO的使用？
前面我已经说过了，如果使用queryString，应该是用command模式，将业务逻辑作为一个command，在业务逻辑之外的command_handler里面使用queryString来获得领域对象。隔离queryString的地方是command_handler，不过这时候已经不是DAO模式了。
如果是DAO的使用，我是支持牺牲queryString的灵活性和便捷性换取明确的接口意义的，也就是说那种“老”的DAO

举个具体的例子来谈谈你的业务层和Dao的设计吧。

加班中，例子举不上，简单说说我的看法
如果确信会使用一种透明的O/R mapping底层的话，使用queryString是没有问题的
这时候使用command模式是很方便的
在command_handler中使用queryString负责获取所有的领域对象，捕获各种异常，然后在command中用领域对象的交互来表达业务逻辑，command运行完毕之后，在command_handler中将更改持久化
如果底层发生变化，更换command_handler来适应变化
这是一种依赖注入的方式

如果使用传统的DAO，那么就是要实现所有要用到的接口，将底层的数据持久逻辑完全隐藏起来。
如果服务层频繁发生需要更改DAO接口的情况，那么说明两个层次都还没有进化好。应该考虑重构或者变更来源的问题
通常频繁需要更改DAO的情况说明业务层面向数据多过面向对象。

总之，我所要强调的，是对象的交互。
如果给业务层的数据库能力太强，业务层就会变成操作逻辑层
这样很容易离开对象，走回以前结构化变成的路线。
而我反复强调的queryString的问题在于他在编译时是不可验证的，没有工具可以帮忙组织整理他们与其他代码的关系。

另外重新说明一句话，我想我表达的不很清楚。

这里关于name字段名称的可能遍及这个service层的更改是指queryString中的更改
类似"select student.name from student"=>"select student.sname from student"