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

分这么多层还是有必要的吧，而且针对接口编程是行业的best practice，还是遵守的好。对于无法预期的变化，这种做法会带来好处。比如dao实现真由hibernate变为ibatis，接口所能带来的好处就显而易见。

另外是成本问题，感觉增加一个接口并不会提升多少开发的成本，因为在实现类中，什么方法名你还是要书写的。

据我的理解，分层的好处在于：

1 团队协作，一个组负责一个层，一个人负责该层的若干个点

2 可扩展性，一个接口可以有多个实现，在大点的项目里这个是很常见的，对于中小型的web来说，还是php rails来的爽

3 可维护性，哪个层出了问题就去哪个层解决

我的看法：

  1.如果是用hibernate，可以不用DAO

  2.的确没有必要在每个功能上都用 一个接口 + 一个类 的套子来自虐。
       a.我们做的不是框架，而是具体的应用，在service这里不需要过多考虑灵活性，DAO就更加不需要了，因为更换持久层框架的事情不太可能发生
       b.用接口+类写成的代码，看起来非常累。尤其是想看一个功能的实现时，要很费劲才能找到接口对应的实现类，然后还要在实现类中费劲地找到具体的Method

  3.其实Service层也可以考虑重用－－将可重用的业务逻辑定义为XxxService，将具体的，直接对应于USE CASE的功能定义为XxxApplication -- 这就是Core J2EE Partterns中的Application Layer模式
      

1.分层目的:
dao与service是为了区别事务的边界.
(这样是为了让 spring 更好的区分)
action以上分成一层是由于struts不好测试,所以很多页面的跳转是不做测试的.
(我们的项目是struts1.0)


2我认为接口是用来写注释的地方
对于程序来说越短越好,但接口就可以写很多.
可以把你的需求定义,用例都写到接口里面.

PS:楼上...如果你的业务不变化.那么结构化编程会更好理解一些.

   同意楼主。虽然我们项目中用了 “接口+实现” 的模式的Service， 但就轻量级开发，我觉得也没必要存在Service接口；按功能建立的DAO接口更没有必要了。 100个功能，就多了200个Java文件，文件数太多了。

1.其实service层接口还是有必要，有一种情况：以后的系统要移植到spring中，然后在service层加入事务控制。
2.楼主所说的view层和action层其实就是view层了，如果有能力的话，控制器可以做几个就够了，比如一般业务一个，工作流一个，用户登陆一个.....
3.如果现系统中没有spring管理事务，刚事务控制可以放在action中，如果有发生延迟加载的话，可以放在过滤器控制，这样子也挺好的。
4.DAO层和services层有的时候可以结合在一起，就是上述情况，事务控制不在services层中进行。

但是，我现在做过的几个项目来看，接口定义是非常有必要的，以后有需要重构的地方，运用比较好的设计模式，就会让你受益的。

你给我的感觉就是觉得service 和dao 没必要同时存在，没必要去对应那些接口。
dao,和数据直接打交道
service,通过dao实现业务逻辑
你可直接实现动态dao
那样的话你就只剩下service了
http://www.iteye.com/topic/232885类似我实现的这样

用Hibernate，基本上大小项目都不需要DAO层了

分层还是有必要的。对于团队来说。可以明确目标与任务。至于要不要DAO层，还是要看项目大小与开发周期。接口的作用在于定义规范，可移植性也会提高。实现也会更加灵活。