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

俺觉得还是分层好，如果熟练的开发人员，分层的代码其实也不会带来多少工作量。

在开始是面向过程的变成，后来演变成面向对象的变成，但现在是面向接口的编程，使用接口可以让任务更好的分配，可是实现横向分配任务，减少程序员的压力。在个人认为Dao层时必须的

现大多项目都是SSH框架的,其实在这个体系中Hibernate或者其他的持久层框架都帮助我们实现了DAO层,我们所谓的DAO层其实只是DAO层的业务简单操作的封装层,但是我要提醒的是系统中各个模块之间的业务不同,如果没有这么一层封装的话,会给系统带来很大的不便,比如:你可能就要将这部分代码写入Transaction事务层(就是这里所说的service层),那么在以后的业务变动时,就要将数据操作和事务一起更改,看起来非常混乱和繁琐,带来很大的不便.面对模块划分和单元测试就显得更加繁琐.
面向接口编程其实这是一个很不错的设计理念,可以使设计者不用关心实现,这是最初需要解决的问题所衍生出来的设计理念.
但是现在他同时解决了DAO实现手段变更的不便,当你的实现手段需要变更时,你可以不用担心其他层的变动,比:Action,Service,View...,你可能只需要修改你需要变动的那层代码,同时不用担心会漏掉某些方法或者错误实现.这样也就更发挥了Spring的粘合作用.
对于需求变更,我们无法准确的预计,只能尽可能的防范和提供灵活的实现才能将项目做的灵活方便.

在软件的结构中应该严格按照层次的划分来组建，不能因为个人觉得有些小麻烦就轻易去掉，这样会个以后的维护以及扩展造成麻烦。但是在分层的时候并不是按照什么view、action、service..等等，而是按照J2ee的层次，上层可以访问下层，顺序不可逆！

个人觉得应该有dao和service，接口也是必要的，首先是从面向接口编程的角度来讲，其次接口可以去掉重复的代码，降低代码的耦合度。像上面说的可以在service层调用dao侧的实现方法，也不会增加太多的代码量，实现的代码结构清晰，耦合度低。

在做项目时，问心自问，你的Service接口有几个实现，你的Dao接口有几个实现。分层是必要的，但每个Service和Dao都只有其对应的，一个Interface和一个Implement，那还有意义吗

强烈怀疑在小项目中使用接口所带来的好处，5，6万行规模的项目使用接口恐怕带来的收益不能抵消其所增加的成本。

接口还是需要的，为什么一定要区分大项目和小项目？小项目随着需求的不断增加和修改也会转化成大项目，除非你认为自己做出来的应用没有进步的意义。
dao一般是一个表对应一个，当然也存在操作多个表或者直接执行原生sql；service通常是调用多个dao去处理事务，并不是一个service只能调用一个dao
我现在的做法是action中既调用service也调用dao，一些简单的查询直接调用dao就可以执行，没必要在service中重复一次；一些复杂的事务或者可能在多个action中都调用的方法都放在service中实现

很同意楼上的说法。。
要不要分层，分多少层应该以项目的具体情况而定

分层本来就是为了灵活，使用接口也是为了应付变化。不要说迁移持久层的实现，就是客户的一些临时的需求变化，也会导致程序很多地方变动。软件就是要应付变化！