java的web架构讨论【散分，来者有分】说明：系统使用了Structs2、hibernate3、spring3框架，使用了基本的三层架构
java的web架构讨论【散分，来者有分】
说明：系统使用了Structs2、hibernate3、spring3框架，使用了基本的三层架构，即：Dao层、Service层、Action层
一、关于Dao层
顾名思义，Dao数据操纵对象，封装了访问数据库的操作，在service层只需调用它提供的接口就可以实现数据库的操纵，无论使用下面的哪种方法都可以屏蔽数据库的信息（无论它是oracle、sqlserver、mysql、db2）
1、有的系统只使用一个Dao对象，即CommonDao对象，把所有的数据库操作都放在该对象中，这样做确实不要写太多的Dao接口和实现类，请经验丰富者说明该种设计的利和弊（包括后期维护的利和弊）。
2、有的系统使用N个Dao接口和DaoImpl，基本上做到了一张表一个Dao，这样有些Dao操作是通用的，可是却在Dao中重复了N遍，感觉挺麻烦，请经验丰富者说明该种设计的利和弊（包括后期维护的利和弊）。
二、关于Service层
service对象，即：业务处理对象，其封装的是业务处理逻辑，action层只需要访问其提供的接口就行了，这样action代码很简洁，在这里我有一个疑问，就是service层有必要实现面向接口编程吗？请经验丰富者说明该种设计的利和弊（包括后期维护的利和弊）。
请大家踊跃发言，各抒己见，来者有分
[最优解释]
史上最端正的学习态度...
[其他解释]
一、关于Dao层
我习惯使用这种方式 一表一个DAO
又错了好找 而且一个DAO多少行代码 很烦
[其他解释]
关注下，我也有同样的疑问，另外，虽然大家不缺分，但是散分是一种姿态
偶没有分
[其他解释]
1、关于DAO层
1）首先这个CommonDao我不知道楼主所说的是那种类型的，但我觉得不外乎两种方式，一种就是有一组公共的DAO方法不关心返回的数据对象，统一封装到一个公共的"CommonEdity"中这个大多数是一个MAP的子类，但是缺点很明显，在数据展示的时候回比较麻烦，需要进一步封装。另外一种就是写一个臃肿的commonDao，这样项目小比较实用，免去了那么多的注入，那么多的xml配置文件，但是一旦工程比较大项目组多人来维护这个commonDao将是灾难性的，虽然svn、cvs很强大，但也很难不出错。
2）对于每一个表对应一个Dao这种情况，我觉得更多的是一种规范，这样的框架设计大多会有BaseDao<T>这样的类来供我们的业务Dao来继承，你会发现，你的很多你的很多的业务Dao其实里面什么代码都没有，因为BaseDao里面的方法能够实现简单的增删改查的。我觉得这样的设计虽然浪费了一些功夫，但是后期维护起来，特别是其他人读、修改代码也会相当容易。
2、关系service层
我觉得既然写代码要规范，service层还是应该要面向接口来编程，这样也有利于你将来程序的扩展。
菜鸟一枚，只是自己的一点理解....
[其他解释]
1、关于Dao，是使用一个Dao（CommonDao）还是使用N个Dao？ 利和弊？解释一下：我意思中的一个Dao是指Service都调用这个Dao进行操纵数据库，这个Dao是通用的，而N个Dao就是基本上一个表一个Dao接口和DaoImpl，而每个Service都调用相应的Dao
一个DAO的优点就是开发起来方便省事儿，一股脑写就行了。缺点就是日后维护、交接起来太麻烦，缺少规范性。
N个DAO的话就相反，开发起来麻烦，成本高，但是日后维护起来要轻松许多。
各有利弊，所以不同规模的项目有不同的选择。
我还没有学到框架，只是看到web开发的DAO部分，自己的一些感想。尤其是自己照着书写代码的时候，很多方便维护的模式对于很小的代码，其优点都是体现不出来的，相反还会增加很多看似无用的代码。基于这样的背景，就会产生这样的疑问了。
2、而Service是怎么样设计的？是一个接口Service和ServiceImpl，还是一组功能使用一个Service？只要说下你们的设计习惯就行
这个问题其实和DAO类似，接口就是起着规范和封装的作用，对于大规模的肯定会有很多，小项目小网站如果接口过多反而会成为累赘。
以上纯属个人观点，本人菜鸟，还不会写代码了。
[其他解释]
楼主说的ssh，我是菜鸟，目前正准备学习这些框架。
[其他解释]
关于这个框架，我们项目的框架也是这个。
提一个问题，hibernate通过hql语句实现对数据增删改查性能的优化。
当查询时候遇到这个查询的效率高低不等的问题。
总之，通过这个事情，觉得用这个框架好坏兼有，尽量趋利避害吧~·
[其他解释]
菜鸟表示飘过……
[其他解释]
问这问题 你应该先理解 为什么用框架， 难道没有框架就不能编程？ jsp原生态 jdbc 连接数据库 不能写web？
框架 顾名思义:就是架构，一个体系，像盖楼，看你需要什么样的楼，就用什么样的结构， 想要盖高楼，盖结实，就要用钢筋水泥 搭出来一个，主体结构，根据主体结构，来完成一层层 一块块的屋子。
不是只有ssh 一种框架的。ssh有它的好处，也有弊端，弊端就是相对庞大了，做一些小项目的话，有搭建 修改的功夫 ，都写完2模块了。
大概看了一下 你的问题，你是不知道 为什么要要面向接口 编程， 对我们程序员来说，最大的好处就是省力了，方法公用，不用写 重复的代码了， 维护起来方便，改一个地方，一样的问题就全解决了，相对清晰
[其他解释]
经验是练出来的。 虽然都用ssh框架。 但是使用也各不相同。
[其他解释]
同意，自己写的代码不光是给自己看的
[其他解释]很久没用SSH了，都忘的差不多了……
[其他解释]框架的出现无疑是为了快速开发和管理，如果没有了框架同样可以开发，同事也会增加开发过程的复杂性。
记得曾经有人在坛子里说过，框架是为了简化开发，如果被框架所束缚了，还不如不用框架。（大概这个意思）
[其他解释]学习学习
[其他解释]我是为了分来的给点吧，呵呵！
[其他解释]楼主这个，我觉得你想太多了。既然你使用了ssh框架，项目一定是不小的，如果这样你还是老实点按照最大众、最标准的方式吧。项目如果是小的话，我建议你直接用jsp+servlet+jdbc来的好（搭框架太麻烦了），我现在的公司就有一个自己用的小项目就是这样的，运行起来一点都不卡。
[其他解释]顶一下！
[其他解释]红色部分是亮点。
[其他解释]刚毕业的新人飘过，来学习的。。
[其他解释]学习学习学习学习学习
[其他解释]学习一下，我也有个问题帮忙看一下http://bbs.csdn.net/topics/390280941 非常感谢
[其他解释] 标记一下，主管走了 ，再细看！
[其他解释]数据层用ibatis不错…学习简单，适合各种水平的人。
[其他解释]service层有必要实现面向接口编程吗？
有必要，而且非常有必要，service层是由spring来控制事物的，而spring控制事务是通过AOP切面类来实现的，也就是你由spring生成的serviceImpl对象，并不是你写的那个serviceImpl对象了，而是一个代理类，所以要通过java接口的多态方式来接受这个对象。我说的也不是很清楚，不知道大家能不能明白，个人意见，也许不是很对
[其他解释]1、关于DAO，可以写一个commonDAO，每个模块再有自己对应的DaoImpl,commonDao提取出共用的增删改查操作，负责数据操作，其他DaoImpl都调用或者继承CommonDao。如果都写在一个dao里，后期维护是非常麻烦的事情。一个类中有太多的代码，谁都懒的看，而且每个人都对这个类进行修改，非常容易出错。
2、关于service层是否有必要实现接口，我觉得可以根据实际情况来定。个人推荐一些关键模块实现接口。比如你是项目头儿，前期就可以将一些关键的功能必须实现的方法定义好，具体实现你可以不自己去写，这样一方面就对整个项目有了规范，另一方面开发时候也减少了代码量，而且维护起来也更好维护。
以上是个人意见，仅供参考
[其他解释]还DAO 写一个公有的DAO父类 直接继承就可以用了 还写什么 系统 生成的都省下了
[其他解释]楼主现在还在迷茫？
按规范写吧
接分 结贴把
[其他解释]C++er，楼主给点分呗！
[其他解释]1.你得遵守现在的规范，即使它很烂！
2.根据我的经验，这些框架都有一个缺点：将业务代码分离成N个部分，而这N个部分好多都是公用的！可想而知以后改起来多么滴麻烦！业务变化或修改问题时，程序员最难的不是找不到需要修改的代码，而是找到了不敢改，因为那些代码是公用的！什么样的代码会随着业务的变化而变化，毫无疑问：SQL（绝大多数）。所以，无论怎样，不要将一个功能的SQL写的到处都是，而且是公用的（最好写在一个方法里，除非那个SQL确实会有很多地方用到）。然后你可以无限的抽离你的技术代码、并且有可能的情况下将其设置为公用代码（与SQL无关，因为那些代码不会随着客户的需求变化而变化）。
[其他解释]你这句话就证明 正规的编程项目你可能没跟过
或这说没看过公司先有的代码
一个DAO里你要写多少行 上万行麽
这样利于程序的阅读么
效率么 每个需要的对象复用更会可能产生问题
这么说 你持久层肯定是用IOC控制反转（DI依赖注入）
那么同时有多个数据库访问 多个数据对象
那么你会都乱 都没有一个整体编码的规划
[其他解释]
不知道你们接触了哪些Dao模式，我的意思很简单，一个Dao的话，就是通用的方法是的很泛，如add(T t)、delete(T t)、update(T t)、find(String hsql)、等等方法，我感觉一个Dao可以解决所有的问题，所以，有必要使用“几乎每个表一个Dao的模式”吗？
有经验的给些经验之谈，无经验来领分哦
[其他解释]
前期对这个问题也是特别困惑，当你维护过一个大项目，经历过需求变更的修改可能会有更多感悟。
[其他解释]
这是一个通用的Dao，当你使用它的时候，不需要关注它是怎么实现的，你只需知道它的接口，拿来直接用，内部代码我看过，也不多，这个问题我们先不讨论，关键是：写好这个Dao之后，就不需要再修改它了，它是一个成型的对象
[其他解释]DAO，所有的表都有增删改查，相同的操作可以提取到一个超类中。写DAO时，直接继承超类，就有了这些方法。不用重复写。
service 面向借口编程。方便多人开发分工。即使service没实现。写控制层的，可以直接调接口的方法。省时间。
[其他解释]是覆盖，写错了，sorry
[其他解释]重载可以搞定
[其他解释]1 关于DAO，其实这是两个问题，接口的必要性，和同一个commonDAO的利弊
问题1： 我认为接口只为了方便同事间协同开发。一个写DAO的，没有必要全写完了，再把DAO通知给写Service的，可以先把接口给他，然后自己写实现。
问题2： 同一个commonDAO的利弊，我觉得更取决于ORM的实现，如果是hibernate之类的，挺好。人家hibernate还不是通过一个session，或者那个什么template的玩意，搞定的？如果是jdbc的话，就设计到绑定参数的问题。我们现在既是如此，同一个DAO（都继承自commonDAO）的不同方法，并发访问时，参数的绑定会串笼子。
2 关于servcie的接口必要性，跟DAO相同
[其他解释]用框架的目的无非是让项目的代码量少了很多，方便了而已，之前用MVC模式做项目不也是做了吗，框架是应运而生的东西，自我感觉，还有就是个人感觉Struts还有Sping没什么大意思，个人还是比较喜欢hibernate这个持久层的框架还是很有用的，再有一点不得不承认的是，现在的这些框架在内存方面为我们分担了许多啊，不必需要极其更高的配置，本人只是发表一下个人的看法，高人可以指教，欢迎
[其他解释]楼主别坑了 接分把
你老老实实问同事
公司流程 那么写
[其他解释]一、关于Dao层
封装在一个里面 没有利，只有弊。没有见过这样的设计。 难道一个对象里面几万行代码？
二、关于Service层
service对象，即：业务处理对象，其封装的是业务处理逻辑，action层只需要访问其提供的接口就行了，这样action代码很简洁，在这里我有一个疑问，就是service层有必要实现面向接口编程吗？请经验丰富者说明该种设计的利和弊（包括后期维护的利和弊）。
有适当的必要。 特别是当你的程序需要提供webservices、 或者rmi服务的时候。
另外如果有合适的注释，看接口比看一个实现类要轻松的多。 甚至有时候也许你根本不想去看其他人的写的一堆不知所谓的“垃圾代码”(呵呵 ，每个人都有自己独特的风格)。
[其他解释]面向接口编程呀，隔离变化。
[其他解释]确实是重载，但是这样仍然需要继承commondao，这样仍然会多出好多类。
------其他解决方案--------------------
该回复于2012-11-17 17:21:15被管理员删除
[其他解释]service层用接口编程，正是java的面向对象编程啊，这里调用相应的类面向接口编程，运用接口概念是为了减少设计模式之间的各层的耦合度，一种规范，通俗一点说就是你好了这个接口，把你项目的需求、业务逻辑等封装进去，然后分配给项目组的其他人；面向接口还有一个好处就是你做的这个web项目以后升级的时候，你所需要做的就是在service接口添加新业务应用，实现类去实现，其他层可以不动，不需要大的改动
[其他解释]你们把你们公司的架构图上传上来，大家共享下，
只要显示到包即可，下面是我的：
[其他解释]上面 只是例子
[其他解释]各有利弊，不过我比较喜欢一个模块一个biz一个Dao一个Action
[其他解释]小系统，任何一个人一眼就可以把握的，可以动手做的时候，讲这些体现不出来优势。
从高层来说，当系统大到一定程度，复杂到一定程度，而且系统不会只是用个一年两年就废弃了，而是要不断的完善，扩展的时候，分系统、分子系统、分模块，把系统尽量隔离开，最小化功能相关，就是很迫切的需要的。
同样分层action、service、dao，职责单一，多个service、多个dao，虽然看起来个别地方重复（设计做的够好，是可以避免的），但是利于简化项目复杂的，利于项目实施和管理。
接口的问题，在大系统设计的设计，架构师和设计人员要考虑的一个重要问题就是模块之间的通讯连接问题，怎么样，分解系统，降低复杂度的同时，让系统组合起来可以更好的运行，这个是接口的主要意义，然后就可以分发下去开发，对项目管理也有很大益处。
这样子做的好处，从底层来说就是得到了高内聚，低耦合的组件，这样子对以后系统的维护、扩展的好处，到处都可以搜到。
对开发人员来说，我只需要关注实现我自己的模块，对管理人员来说可以更好的安排工作，控制工作进度。对于bug的定位和修改也都容易的多。
[其他解释]接口是规范，类是实现。OOP即现实中所有事物都可以看成是对象，接口就是用来描述事物特征的。其实太多的接口是写给计算机看的。其实没有写个大量函数式编程的，是不能真正的领悟OOP的。
[其他解释]降低模块间耦合更符合软件工程的思想。维护起来会省很多麻烦。
细粒度的结构划分可以更精确的定位。比如aop的切面定位，事物划分等。
没见过用一个DAO的系统，不做评论。
[其他解释]我现在正在学习ssh，你们都懂的太多了
[其他解释]null
[其他解释]先自己UP一下
[其他解释]二、关于Service层
1 2 问题你都说道面向接口编程
接口是什么 抽取事物相同特征
既然相同的多就抽取接口 如果
类不具有共同特征当然不必使用接口
而且首先定义你程序共同的工具通用接口
也利于程序的开发 加快速度
同上你的第一个问题 我亦适用此
[其他解释]对于你说的接口的定义，我表示赞同，但是，接口在另一个层面，起着规范结构的作用，并且在多层次的设计时，接口相当于上层对象访问该层的通道，这样就封装了该层实现的具体细节，即上层不需要关心该层是如何实现的，如果该层要替换、要整改，只要满足该层的接口，就可以随便整改该层
但是，我不明白service层面向接口编程有什么意义和作用？service层不像Dao层，需要屏蔽数据库的实现细节
[其他解释]关注点是红色字，大家不要偏题
[其他解释]http://www.blogjava.net/skywind/archive/2011/06/02/351638.html
[其他解释]还有就是 你问的 为什么 有的 是把action service dao 每一样相对的都写一起， 相对小的项目，紧密性高的 写一起方便，不用引用那么多包，不用来回继承。 缺点就是 ，大项目 怎么办？ 你打开一个action 里面有 十来万代码 你还有心看么。找个 action 得累死，改个错误都闹心死。 维护起来，删一个功能模块 找就得找半天，不好移植。
一般情况下，Domain 是 按功能模块开发的实体表， 所以相当于 按照功能做模块，往框架里套。 来解决上面的问题。
公司也有考虑，可以避免 你看到别人的代码，每个人的代码相对独立，可以控制个人盗用 完整的公司项目源码。 这也是按domain 划分的好处 之一，互不影响。 2个人都想用一个方法名就可以用，因为不在一个模块下，不在一个路径下
[其他解释]孩子 框架只是能让我们 更好，更快的开发， 主要思想 就是 高可用。
给举个例子， spring 我感觉 最好的东西 就是注入和注解，
java 定时器，你每次写一个方法 要开定时器，就不断的写一个方法 run一下。 定时器多了，很费劲。
spring 定时器 配置完 注解 就一句话 加在你方法 上面就行了
@Scheduled(cron = "0 1 0 * * ? ")//每天凌晨0点1分执行
[其他解释]感觉你经历的蛮多的，我还没有达到你那个层次，我就问下具体的问题，或许比较幼稚，但是，不问就不知道答案
1、关于Dao，是使用一个Dao（CommonDao）还是使用N个Dao？ 利和弊？解释一下：我意思中的一个Dao是指Service都调用这个Dao进行操纵数据库，这个Dao是通用的，而N个Dao就是基本上一个表一个Dao接口和DaoImpl，而每个Service都调用相应的Dao
2、而Service是怎么样设计的？是一个接口Service和ServiceImpl，还是一组功能使用一个Service？只要说下你们的设计习惯就行
求指教，向牛人致敬
[其他解释]呵呵，或许太死板了，可我就是想知道别人是怎么做的，为什么那么做，求指教
[其他解释]很好的文章，谢了
[其他解释]该回复于2012-11-13 21:28:06被管理员删除
[其他解释]1、Dao通用的话，也可以 和我说的action一样，小项目，数据库连接相对少的时候，往往都是传参数 动态使用Dao，可以最大的公用。 相反的，写多了，这个Dao就相对很臃肿了，大点的项目的话，还是几个domain 对应 一个功能模块，对应一套 action，service，Dao ，这样相对清晰，而且 每个人一个模块，这样互不影响，相对给每个程序员编写代码的空间也比较大，在不违背编码规范的前提下，想怎么写怎么写。 而且有的公司，需求跟（和谐）一样，我怀疑他们都不知道自己想要什么，对一些模块改了又改，还让你设计，最后不要了，设计 想射他们一脸（和谐和谐），要是都公用的话，你就会不断的改，还不能影响别的模块，最后改的面目全非不想动这块了都，分开就好了，直接 模块删了，也不影响别的模块。
------其他解决方案--------------------
说的对呀，ssh 大家都在用，每个公司用的还是不一样，还是根据项目和领导 来决定的。没有好与不好，只有相对的 更适合。 可能这么用大家都能说出很多缺点，我只能说 这样更适合这个项目。
[其他解释]2、一组功能使用一个Service，因为 一组功能对应一组domain，因为一组功能相对来说是相互影响的，domain也在设计的时候 就应该考虑了关联性了。
[其他解释]我们公司的一个项目蛮大的，使用的是通用Dao，里面写的是通用的方法，没有处理不了的数据库操作，没有什么问题的，而你说的domain是什么意思，具体点吧，我看到有些人的文章，他们说面向domain设计，我不太懂
[其他解释]我是不管做什么都分层 都要有接口
上班公司 不论大小项目都是需要规范的
而且这样后期维护和开发 有整体性
我建议使用接口 如你所说
你的service层 可以不使用接口么
可以啊 但是你抽取共同特性的方法做成接口不好么
估计你是刚学把 action显示层 调用 service - dao 持久层
然后你的service是用来做中专调用dao就转个参数是把 ？
根据你的需要订 service可以不使用接口 根据项目规范走
[其他解释]Service层，我没接触过面向接口的设计，我手上刚好有一个新的项目做，可以按照自己的设计去做，所以我想把它设计的好些
[其他解释]domain具体的表现是怎么样的？domain只是起功能划分的作用吗？还是专门有一层（如Dao层、Service层）专门表示domain
[其他解释]你应该先理解下 面向对象编程。domain就是表结构，或者是数据的实体表。 为什么只有老鸟做主导框架设计，因为他们见过更多的东西，或者说 阅历在那里，新人 我们会问，你知道哪些框架，它们有什么各自独特的好处， 问老人，就是问 你们都用过哪些框架，它们的各自的不足，并如何弥补。 只有自己用过，并被其中的好处而吸引，被其中的不便而恼火的时候 你就理解了。
你们项目蛮大的话，dao实现 最少得2w来行代码了吧。为什么这么设计 你应该问问你们领导，有什么好处，每个人的理解是不一样的，可能那么设计更适合你们的项目
[其他解释]那个项目是05年开发的了，我前一段时间只是给这个系统升级，它的通用Dao不大，很简单的一个对象，假如你要查询，就用query（hsql/sql），很简单的
[其他解释]你如果真的是想自己设计的话
我建议你用最简单但却规范的
domain是域模型 就想你的实体
javabean，
使用工厂设计模式
分为action包 service 包
然后dao包 daoimpl包
...
这样起码让人觉得你是有系统的做东西
[其他解释]代码都是人写的
你首先要知道你需要什么
什么框架
每个人都有编码风格
不过也不能太独特
毕竟你是在工作 不是自己单干
------其他解决方案--------------------
首先 必须要使用接口
前两个问题，如果业务多，当然要使用多个DAO，但是如果有共同的地方，你可以抽取一个公共DAO啊，这都一样的，业务性独立的还是用多个。
好处是 维护和扩展啊，你现在即使业务不多，以后如果逐渐增长呢？ 都在一个DAO里一旦某个业务发生变化，或者某次更新代码，就使所有业务承担了风险。
BS层也最好接口，接口的好处太多了，当然要看你的项目大小业务级别。
但是即使很小，也没多大坏处。
比如多个人员分层编写代码，代码规范性，后期更改维护都会方便很多
[其他解释]关注++ 少于6个字符不让发送，就加点后缀吧
[其他解释]不应该把数据源限定在一个表，而应该是一个能够获取相似数据结构的任何东西，比如视图、存储过程、webservice、其他系统的接口...这才是dao的目的，让数据源透明
[其他解释]看来楼主没有接触过复杂的业务逻辑吧，想你一下移动有多少套餐，你要是编程实现会有多么麻烦，如果只有一个commondao，你不可能把所有的底层业务sql都写到commondao里面吧！另外，如果不用很多daoimpl,那么这些业务sql就要写在services里面了，service里面的代码就会相当复杂，即有业务逻辑的，还要有事务控制的，还要有业务逻辑sql的。。。后期一旦改变需求，就能把程序员弄个半死（这个是很经常的），如果业务sql写在commondao里面就会出现影响所有的其他类使用这个sql，可能会造成许多异常。
另外，在程序方面，如果你的版本已经定了，也就是说经过了多个部门共同努力（包括测试，编码等等），如果需要变更，你更改了commondao，那么就要把之前的东西可能都要测试一下，想想工作量。。。。
另外，services里面和这里的情况也是类似的。
其实项目做大后，不要只在代码层面说省事就可以，前期编码只占程序的一部分，后期的维护和需求变才更重要，只所以分多层，面向接口来编程，就是站在工程的角度和节省后期维护成本的角度来说的。
其实我建议可以看下企业级的应用程序开发的原则和设计模式，那么这个问题可能就会有一个全新的认识。
[其他解释]那你还想问什么
代码可能不修改么
你感觉直接写dao是没错
不过定义接口更规范
还是那句话 写代码也要
有规矩 按公司规矩走把
[其他解释]刚刚开始学hibernate！
[其他解释]1、有的系统只使用一个Dao对象，即CommonDao对象，把所有的数据库操作都放在该对象中，这样做确实不要写太多的Dao接口和实现类，请经验丰富者说明该种设计的利和弊（包括后期维护的利和弊）。
=========================================
这样做个人感觉是不大好的，只用一个Dao对象，可能导致这个Dao代码过长，太多人维护。利益我暂时没看到。
2、有的系统使用N个Dao接口和DaoImpl，基本上做到了一张表一个Dao，这样有些Dao操作是通用的，可是却在Dao中重复了N遍，感觉挺麻烦，请经验丰富者说明该种设计的利和弊（包括后期维护的利和弊）。
=========================================
这个还是凑合 不一定要一个表一个dao 也可以相关的类公用一个dao 至于某些Dao 操作是通用的，你可以抽取出来，放在父类的Dao里边。这样以后要修改通用操作的时候只用维护这个父Dao就可以。 其他地方也应该是有公用的代码就放到父类里边。
二、关于Service层
service对象，即：业务处理对象，其封装的是业务处理逻辑，action层只需要访问其提供的接口就行了，这样action代码很简洁，在这里我有一个疑问，就是service层有必要实现面向接口编程吗？请经验丰富者说明该种设计的利和弊（包括后期维护的利和弊）。
======================================
这个没有太多经验...
嗯 以上是我的看法 欢迎拍砖 也是新手学习 哈哈
[其他解释]菜鸟飘过、、、、、、
[其他解释]null
[其他解释]求共享，求分享
我先来共享一篇文章 http://blog.csdn.net/shaily/article/details/4308449
[其他解释]null
