Dao设计

Dao的设计，如果作为大接口使用，那么Dao接口应该是泛化接口，是通用接口，尽量节俭。

一般都是 int insert(T t);
一般都是 int delete(T t);
一般都是 int update(T t);
一般都是 T queryList(T t);
一般都是 T queryList(T t,Page page);
一般都是 T queryOne(T t);

如果当大接口不能满足条件下，这样的为定制化服务的，那么尽可能每一种为提供实现。
比如:
       int updateResult(List<User> list);
      
       User对象包含一个关联Acount银行账号集合。

那么，这个方法就属于定制化方法。



这里还是有点悖论的。我希望将这种操作丢入到dao里面，由dao来完成里面持久化操作。但是，事实不得不这样。



因为User与Acount关系是聚合关系而非组合关系，所以，Acount可以单独存在，自然有Acount的Dao和Service层。

而我们很多情况都是应用到了spring的DI功能，所以，对于updateResult这处理只能放到User的service去，由

User的service来通过spring DI 来生产Acount的service进行协作处理。这样，情况很明朗的，但是操作的后果

也很大的。因为在我看来这是框架影响到我们处理，从操作数据库角度来说，这应该不算业务逻辑，应该放入到Dao里面

处理的，我们聚焦是业务逻辑，结果导致Dao变得很弱，而service变臃肿了。


而这样的结果，很让人压抑。而这点，做过GUI/SWING的人是深有感触的。


其实处理也不是没好处，还是显而易见的，主要还是减少了各类底层Dao互相调用出现耦合高的问题，防止底层的修改出

现的牵一发而全身的局面，而在service这样处理隔离Dao，隔离底层实现与业务逻辑，使service变得比较灵活。


相对来说，如果是SSH或者SSB的框架架构，必须要这么用。

但是，作为平台或者多线程后台或者GUI开发，也肯定会有业务逻辑，鲜少很看到service的分层，，也很少用

service去定义。这是为什么？因为构建系统的时候，更多的考虑的不是CRUD操作，而是OO抽象和个性化的考量。这样

的思想与MVC分层是相背离的，service当然鲜少出现。 （再续）

我觉得楼主应该思考“一般都是”和“它应该是”的不同。

如何被称其为“自然”和“只能”，我想这只是你的心理暗示而已。

TSheep 写道
我觉得楼主应该思考“一般都是”和“它应该是”的不同。

如何被称其为“自然”和“只能”，我想这只是你的心理暗示而已。





我想说你不去学心理医生，真浪费人才。


做程序开发，很多情况不是“应该是”，因为每种方案都是各自的优缺点，在这种情况下，“一般都是”与“它应该

是”是区别很大的。


你总不能认为自己是对的，所以，对于可争议的地方，用“一般都是”，怎么是心理暗示，并且这还是来自从实际工作

中得到经验。

我并非是那种“它应该是”非得强调什么，而是抛砖引玉让大伙发表建议。

关于你的理解，我实在无语。

DAO部分，可以提供基本数据完整性验证保证写入不出现错误和保证表关联性。
复杂操作部分，在不考虑数据库水平迁移的情况下，尽量让SQL通行，降低学习和开发复杂度，降低DAO方案变更导致前后代码变更。
DAO层技术很多，针对是不同的项目情况，选择合适的，而不是功能强大的或流行的。就足够了。

你说的概念有点混淆，实际上DAO部分也可以继续分层，基本数据访问层，和数据完整性层。DAO部分设计的基本概念：满足数据模型的合理性，而不是满足业务逻辑。至于对外，只要提供数据操作的方式就可以了。然后在业务逻辑层，对流程进行控制。

jackra 写道
DAO部分，可以提供基本数据完整性验证保证写入不出现错误和保证表关联性。
复杂操作部分，在不考虑数据库水平迁移的情况下，尽量让SQL通行，降低学习和开发复杂度，降低DAO方案变更导致前后代码变更。
DAO层技术很多，针对是不同的项目情况，选择合适的，而不是功能强大的或流行的。就足够了。

你说的概念有点混淆，实际上DAO部分也可以继续分层，基本数据访问层，和数据完整性层。DAO部分设计的基本概念：满足数据模型的合理性，而不是满足业务逻辑。至于对外，只要提供数据操作的方式就可以了。然后在业务逻辑层，对流程进行控制。

同意.
把dao层设计成service层是很杯具的事情。

用grails吧，dao层不用你设计，开发效率绝对高！

一般使用ssh的时候，个人习惯就是dao没有任何的逻辑，就简单的实体crud，而不会去添加任何逻辑，有时候这个看上去有点别扭 但是这个是dao的本质，这个样子就造成了service很臃肿 这个我现在也是无法避免的，还在找寻一种更好的方式   

把根据业务订制的部分分离出来就好了，相当于再封装一层dao，最好能把配置xml化。这就是持久层框架干的事。。。

  dao层的设计应该更细粒度话，我认为不应该在dao层中嵌入任何逻辑，只有这样的dao才有可能被service层所充分复用。。
  service层所做的就是校验数据的合法性，事务的处理，异常的转化与通知等工作。

nirvana1988 写道
  dao层的设计应该更细粒度话，我认为不应该在dao层中嵌入任何逻辑，只有这样的dao才有可能被service层所充分复用。。
  service层所做的就是校验数据的合法性，事务的处理，异常的转化与通知等工作。



书上理论上大家都这么说dao层越细粒度越好。但有时候实际开发中，这样做没有任何好处，为了追求更完美的细粒度把时间已经浪费了。什么事都没有绝对，当团队开发，每个人只负责自己的模块时，有多少东西能充分的复用呢，所以往往还是各写各的。如果根据自己的业务，灵活运用，适当的在dao加点部分service层的东西也是可以提高效率的。