关于J2EE项目中三层架构如何在开发中得到正确的实施

 我现在参与了一个广电项目的开发，项目采用了目前比较流行的框架进行系统的架构Struts2+sping+hibernate，项目的包结构主要分成Action、Service、dao这三层，Action层负责与web界面进行交互，接收界面传来的命令，然后展示不同的界面；Service层服务具体的事务处理，Spring的事务配置在这一层，这一层为Action层提供服务；Dao层就是为了和数据库打交道，进行数据的存取。同时，分成三层，也可以使类或功能得到复用。但是在实际的开发中，由于项目成员技术层次不齐，大部分是刚毕业或工作一年的，大部分代码集中在了Action层，Service层和Dao层成了摆设。

     我觉得，在这三层中，核心层应该是Service层，不管Action层和Dao层怎么变化，只要这个功能的处理流程不变，Service层的方法应该也不用变化。走读原来的代码，发现在一个Action方法里面都是多次调用Service方法，也就是说本来应该在一个事务里面的逻辑，现在分散到了多个事务，除非真的有这个必要，但大多时候，一次操作是一个事务。

     另外，Service里面能不能写Sql?我觉得这个得具体问题具体分析了。比如最简单的查询数据，需要根据参数的有无来拼查询条件，拼查询条件也算是业务逻辑了，所以拼查询条件的Sql可以放在service层；又如，根据ID获取数据，这个sql就应该都在Dao层了，Service层只需要判断ID是否为空就行了。

     三层结构的有一个目的是为了功能复用，所以Service层和Dao层的接口必须要尽量定义良好，不然很难达到复用。怎么才能达到接口定义良好？我认为需要不断的对代码进行重构。这几天在扩展项目中一个子系统的功能，发现有几个方法实在太长了，最长的一个竟然占了三个半屏幕。看到这样的代码，我第一个想到的就是代码重构，浏览了一下，发现里面还有重复的代码。如果你的代码太长了，一定要把它分成几个方法来实现，太长的方法很难让人看下去，更不好修改。

   上面谈到了在开发中的一些问题，那么如何避免这些问题，怎么保证这三层各司其职？

   第一、在项目实施过程中要定时进行代码走读，及时发现问题。这个最好由项目小组长进行。

   第二、开发人员相互检查，多进行这方面的沟通，通过沟通发现问题，找到更好的途径。

   第三、制定代码规范