struts中业务逻辑位置的问题

系统是struts-manager-dao的架构
现在的观点是action中不放任何有关业务逻辑的东西，所有业务逻辑都在manager层中实现，这样便于控制事务和层次清晰。
可是这样就造成了action中代码很少，就是取得数据，构造对象，然后调用manager中的方法；而manager中的代码确非常多，多得长达一两千行，而且对应每一个业务需求都要封装成一个方法，很多简单的select-update功能相似，流程有区别，也要做区分，感觉manager中方法众多，太庞大了
大家做的项目是怎么对待这样的问题的呢？

难道这就是这种Transaction Script设计模式的弊病？可是这种模式毕竟使用起来很习惯，也很熟悉了。

可以考虑使用这样的组合：
hibernate + spring + struts(tapestry)
hibernate作数据库操作，不关心业务逻辑；
struts(tapestry)作表现层，struts action不直接调用hibernate负责那一层的代码，实际上数据库操作实现类使用了那些工具对表现层开发人员来说是透明的。
spring作为一个桥梁，连接struts 和 hibernate这两层，同时将业务逻辑代码放到spring 这一层。

struts form对象可以直接调用hibernate操作的实体对象；有人也提出DTO对象的概念，目前觉得没有使用的必要，对于一些界面操作涉及多个对象的情况，可以考虑使用DTO对象，一般的界面操作可以直接调用实体对象来完成，如基础资料的操作；

可以看看下面的文章，写得很详细：
http://www.onjava.com/pub/a/onjava/2004/04/07/wiringwebapps.html

那样确实是一个可能的方法。可是问题是现在改变架构会有时间上的问题，而且也要考虑学习成本。
我的意思是有没有在现有这样的架构下比较好的应用经验，来改善设计。

struts-manager-dao
      |---bl

http://forum.iteye.com/viewtopic.php?t=5282&postdays=0&postorder=asc&start=0

我是这么做的Struts ＋BO ＋DAO和你架构差不多，
也许是做比较简单的业务处理吧，重来没有出现一个BO中的代码有几千行的情况。

gigix的groller框架（有source code）清晰地说明了这种分层，和楼主的思路大同小异，可以参考的呀。