分层结构的方法的参数的传递

   楼主列的问题是大多数系统存在的问题，也就是常见的杠铃型，两头大中间小（业务层与表现层之间的接口层，比如Action类，比较复杂；数据库访问层DAO，ORM处理比较复杂；而业务层非常简单，就变成了转发。），至于问题的原因，呵呵，就是你们系统的所谓架构师只有两三把斧头的原因，只会照抄和模仿，知其表而不知其意。
   楼主所在项目的问题就出现在了业务层。楼主项目的做法肯定是表现层需要什么，就设计web service，然后在变成业务层。这样的话，这样一个所谓的业务层其实是没有任何意义的。
   真正的做法应该是：系统在进行分析设计的时候，明确系统所提供的功能与服务（而不是给UI的API），这种功能与服务是组件复用的最大基础（而这也是基于SOA架构的一个最为核心的思想，并不是有了WebService就是SOA）。在业务层，每个方法应该就是一个用例的具体实现（或者使用Facade模式，包括或使用其他方法，就如同用例之间的use/include），应该是事务控制的核心，更加应该是系统服务实现底层的封装，包括系统缓存、中间件服务（消息处理），事件处理等等。
   而WEb Service成一个关键因素，是基于契约（如果对外就应该是基于WSDL，如果对内-UI表现层，就应该是基于DTO的服务封装，类似于JEE核心模式中的Delegate）来定义的。它的主要职责是负责将客户端（外部调用或者DTO）转换成系统的业务可识别领域，并处理一些非业务的系统功能，比如授权与认证等。它可以做成适配器、桥也好，它的核心是委托。
    （太晚了，有些困了。眼睛都花花的，不晓得是否说清楚了，改天再上来看看）

凤舞凰扬，你的想法我觉得很有道理，但这这里其实存在一个问题的。 你说的 “明确系统所提供的功能与服务”最后还不是体现在UI上吗？所以如果说有人“表现层需要什么，就设计web service，然后在变成业务层。”也无可厚非吧。关键是做的时候是否进行功能点归并等的工作吧。

公司的项目分层，是公司自己搭建的框架，分为form层、web service层、biz层，其中biz层负责访问数据库，web service负责调用biz层，而form层则不和biz直接打交道，而调用的是ws层。在这当中，经常会用到这种情况。其实form层需要调用的方法，其实在ws和biz层使用的都是同名的方法，这样也方便调用。本来这样也无可厚非，而且还更不容易出错。但是这样，业务模块多了之后也发现另外一个问题。因为各层的方法名以及方法参数几乎一摸一样，在开发的时候，写每层的方法还可以直接copy和paste，但是一旦修改起来，这可就麻烦大了。重复工作量大。而且最要命的是方法不修改，但是修改参数个数或者参数类型，结果稍不留意就会把类型搞错或者参数不对应。后来有一想法，但是始终没有最后这样实施，但是个人觉得，这样还是很有好处，可能上层决策层不这么认为吧。
比如一个方法GetAllEmp（string name，bool sex, string address, int age），这里有四个参数，这样每一层都会有一个GetAllEmp（string name，bool sex, string address, int age）方法，但是我的想法不是每一层都去写一个参数，而是把参数封装起来，封装成一个对象一个ArrayList对象或者是一个object对象，这样在层与层之间方法的参数的传递的时候，就不会去在意这些参数的类型与个数的问题。当这个单个的对象传递到具体的层的时候，在对这个对象进行类型转换。只要在当初封装的时候没有问题，这个对象的封装与解封装是应该不会出问题的。这种方法，至少到目前为止，可能是因为我的目光以及水平问题，还只看到了他的有点，他有什么缺陷还真没有意识到。
抛砖引玉。