在项目架构中如何进行分层才是最合理的？

     目前很多项目在框架搭建时都遵循以下的分层关系：View层、Action层、Service层、Dao层。在Service层和Dao层中，一个接口文件对应一个实现类，无论是大项目还是小项目，都按照这个模式去做，说这是软件架构的标准做法。本人觉得，一个接口文件对应一个实现类这样做有很多缺点：

     1）创建的文件数量太多。

     2）增加了开发人员的工作量。

     3）增加了后期维护的复杂性。

     4）程序调试不方便。

其实，Service层和Dao层的接口文件完全可以去掉的，只需要具体类就可以了，而且Dao层也不是必须的，可以作为可选层来处理。当Service层的一些方法需要在多个地方引用时，才增加Dao层，用于存放这些公共方法。

 

     SpringSide就是这样做的，不知道大家的看法如何？

适合的就是最好的。标准做法只能说是参考。

就我个人理解，作三层的目的最大的作用是消除重复代码，同时使项目更容易理解和扩展，当然也有很多教科书的说法，比如说移植性，但实际上真正有用的就是消除重复代码。
  另外对于接口的看法，看项目了，如果项目较小，不用接口没什么影响，如果项目比较复杂，接口还是能带来很多好处的。

在任何时候，请使用面向接口的编程方式，尤其在项目不断膨胀的过程中，针对接口的编程会为你带来无穷的好处。

适当做调整
service 层可以按模块去划分。而不必一个实体一个service

dao 可以这么干

service用接口主要是为了配置spring 声明式事务。
而如果你的的dao不会有很大的变化的话，可以不需要接口。
如果某天你需要要准备两种类型dao（比如一种hibernate，一种ibatis的）随时切换，面向接口编程可以带来一点方便，不过这种情况不多，所以我也一般不提取DAO的接口。

项目不大，并且业务逻辑相对来说比较简单，感觉没必要！

个人觉得DAO完全没有存在的必要

我们现在Service是从dao继承的,但是做到一定程度的时候我觉得还是分开比较好,
比如说:service和dao中都有save方法,但是语义是不同的,service中需要处理相关的内容,但是dao中不需要,从这个角度来说,可以service先从一个通用dao继承,省去dao层,需要的时候再慢慢丰富

如果使用aop的话还是要接口的,可以先不写接口,等要用的时候再提取出来

总之,尽量推迟成本的付出,但必须付出的成本一定不要省

我觉得应该是在service中调用dao的save方法，但dao只是一个具体的类。只是处理与数据库有关的事情，就是增删改查。业务相关的放到service。