说明：系统使用了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框架。 但是使用也各不相同。
------其他解决方案--------------------------------------------------------