关于Service和DAO层的功能划分的迷惑

业务层继承DAO层,Service 肯定要访问多个DAO的,这个继承的方案有些行不通,现在已经快疯了:)



现在的业务基本都是这种简单的情况,因为复杂的方式要求写存储过程. 简单情况如何合并?不是很理解

将如上代码放入DAO的超类中,这样我每一个DAO就不需要重复写这些功能雷同的代码!不知道有什么不合适之处.

无论怎么简化dao层，dao对外的接口是不变的，最终业务层还是要是调用dao层的方法，还是会出现楼主的问题
我觉得既然项目业务比较简单，省掉业务层也未尝不可， 在web层直接调用dao 。
如果遇到业务操作就写在dao层，或者web层。

直接使用dao层是比较不合理的，dao层封装的通常是原子化的操作，业务层是组织业务逻辑的，目前service层可能只是简单的调用dao层的方法，不代表逻辑变化之后需要更加复杂的逻辑，这时不可能直接修改dao层，有可能破坏别的service方法对当前调用的dao的逻辑。

例如：原来有个客户保存的dao方法，被一个service方法调用，同时这个dao方法直接暴露给前台，这时如果直接暴露的方法要预先做个判断客户的某个条件，而原先引用这个dao的service方法不需要这个逻辑，难道直接修改这个dao方法吗？

系统开始可能觉的这样比较烦人，但是要有长远的考虑。

我一直以为Service层的接口声明应该是清晰，你这样所有的save,update,delete之类的参数都是Object类型的参数了！

分层架构：分层架构有助于将大系统分解成子任务，每个子任务限制在一个特定的层次上，层间从上到下依赖，从下到上是松耦合。TCP/IP分层模型是它的最好证明。正如OSI 7层模型的实用模型是TCP/IP 4层模型。MiniFramework中，用户接触到的是两层：表示层和业务层，是J2EE和.NET架构的一种折中。在用MiniFramework开发时，持久层被封装起来，成为一些简单的Helper类，不是独立的一层。
之所以我去掉了持久层，只保留的dao helper，是因为，我发现业务比较简单的系统，往往开发人员喜欢在持久层里面写所有的业务，service层只是dao的一个delegate，非常 thin。要是这样，我就干脆去掉一层算了，这便是dao helper的由来。
严格的分层，可以让表示层的UI用Dreamweaver开发，业务层容器外测试，实现敏捷开发。
接口：在分层模型中，一般都非常强调接口，因为可以让上层只依赖于下层的接口，而不是实现，这样实现可以任意替换和变更，在网络开发，特别是和协议打交道的时候，我们会体会到这种设计的优雅。另外，在组件式开发中，我们也倾向于提供接口。
但是，应用MiniFramework，我们倾向于纵向开发，也就是说，某个模块从表示层到持久层都是一人开发，而不是横向：表示层的去调用业务层开发人员的业务层。这时候，纵向开发就不太适合用接口了，因为接口规范完全由本人把握。这时接口很可能只会带来臃肿，和难维护，一点改动往往牵一动百。当然，在某些情况，如开发Mock测试，Web Services，接口还是很有必要。另外，有人说，我用接口可以实现任意层替换啊？譬如我现在用Hibernate，以后换成IBatis。这完全是一个谎言，至少我看到的大多数应用，将Hibernate换成IBatis的成本绝不亚于重新开发，因为耦合太大。另外，我有个疑问：需要更换的可能性有 1％吗？
个人觉得，接口比较适合于系统软件开发，而不是商业软件开发；而抽象类的继承机制比较适合商业软件开发，而不是系统软件开发。为了复用，系统软件开发倾向于组合，而不是继承。

不妨看看我以前写的一篇文章，里面有代码和guide，http://zwchen.iteye.com/admin/show/47085

对于你的疑问，我的看法是（摘自原文）：

你有没有想过,写 一些简单的业务逻辑是可以放在DAO里,但要是整个系统很大,业务逻辑很复杂,你会怎么处理呢,我现在在做交行的基金托管项目,业务出奇的复杂,涉及了个方面的知识,有财务会计,证券,股票,基金等等,我觉得还是分开来比较好!!

如果系统业务简单
可以抽象出通用的dao层(也就一个类)
让业务层继承通用的dao

为什么不考虑这里用泛型?