读《设计模式解析》后对Dao层的重构

看了一下第二种方法 觉得这种想法不错 但是实际应用起来会怎么样呢?
如果我们采用Jdbc，没有问题 可以很简单的切换到oracle或者sqlserver
但是如果要从jdbc到hibernate呢 ，只是一个OrgnizationDao肯定不够用 必须要抽象出接口用不同的api实现（或者其他方式），这样的话结构是不是太复杂了？
我还是觉得敏捷的方式比较好---增量设计。

嗯，同意xly_971223的观点

首先第二种方案是一个很优雅的设计，这种设计在某些系统中应该很值得借鉴的；

但是第二种方案相比第一种方案，它的最大价值是可以动态切换SqlDialect实现，而它的代价是增加了系统设计的复杂性，如果这种动态切换价值是可利用的，那么这种额外的复杂性就是值得的，但是在实际当中其实较少需要这种切换性

在实际开发当中我会按照XP的做法，采用简单设计

方案二和方案一中的接口变了？
如果是接口方法变了，那就是实现不同的功能了。
如果接口方法没变，只是换了个名称，本质上并无不同。

方案一中的工厂被方案二中的Dao替换
方案一中的Dao接口被方案二中的SqlDialect接口替换。
并没有什么实质差别。

楼主的思路与我最近思考的装备模型很像，
我也是围绕着DAO层考虑的，在想有更好
的方式。把对象包装起来，把属性对象和
动作对象聚合起来的方式管理业务模型。
如果有时间请看一下我的两篇文章，给我
提一点建议。

对象，你喜欢极品装备吗？
http://www.iteye.com/topic/79536
实现DDD装备模型
http://www.iteye.com/topic/81086