SSH分层架构的问题
在开发一个项目：最开始打算分层架构这样做：
Action——————struts2
Service-----------服务层：供Action调用，分接口和实现类，用于spring的控制反转，依赖于接口而非实现
AL--------------业务逻辑层：实现业务逻辑，供Service调用
Dao-------------数据访问层：通过hibernate调用数据库实现数据访问，供AL层调用


刚写了几个交易，发现真是太繁杂了，需要一层层的写，一层层的调用，spring配置也要配置很多，于是进行简化，去掉AL层，Service层实现类直接调Dao：
Action——————struts2
Service-----------服务层：供Action调用，分接口和实现类，用于spring的控制反转，依赖于接口而非实现
Dao-------------数据访问层：通过hibernate调用数据库实现数据访问，供Service层调用

现在觉得还是繁杂，打算直接去掉Service层，直接Action层调用Dao。
写了一些代码，发现大多数情况下，Service层的一个接口就那么一个实现类，压根没有多个。

各位架构上有经验的牛人们，给点意见。

------解决方案--------------------
action、service、dao
最少不能少这三个。
如果你把service去掉，那么：
1.代码耦合度增加。
2.分层不明确导致分工不明确。有的公司每层都有单独人开发。
3.回滚问题。比如，一个业务操作，需要在其个人账户和公司账户上分别减少一笔钱。一般是在一个service中，调用2个dao.如果你去掉service,直接全写action中。如何回滚。