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

公司的项目分层，是公司自己搭建的框架，分为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对象，这样在层与层之间方法的参数的传递的时候，就不会去在意这些参数的类型与个数的问题。当这个单个的对象传递到具体的层的时候，在对这个对象进行类型转换。只要在当初封装的时候没有问题，这个对象的封装与解封装是应该不会出问题的。这种方法，至少到目前为止，可能是因为我的目光以及水平问题，还只看到了他的有点，他有什么缺陷还真没有意识到。
抛砖引玉。

（    ）

理解一下业务....看看参数是否是一个 bean的片段....如果是的话...{
    用这个bean.

}如果不是,看这个参数数量是否大于3.{
    不大于3可直串.
}如果参数大于3{
    用map传.
}其它{
    新建一个传参bean
}

GetAllEmp（string name，bool sex, string address, int age）
这个方面当中的参数应该是一个Entity的一部分吧，可以直接传这个Entity的对象啊。
如果按楼主说的将参数都放入到ArrayList里面，那么代码的可读性是不是就被降低了么？还有就是出错的概率也增加了

概括的忒经典了。
在Map和DTO中，你可以做以下权衡：
如果为了减少DTO的数量，那就用Map，但是你没法在编译期检查变量名之类的错误。
如果为了显式的语义和在编译期查错，那就用DTO
用Map的方式你也可以封装一下，但是基本的意思是差不多，封装的理论知识可以参考SDO规范。

参数接口+Adapter模式

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

没错。就是把业务放到Action或Dao中了。我觉得把Dao作为一个组件看待的话，完全可以直接调用，不用非得傻傻的写个转发的空方法。当然，这个前提是业务只是最简单的CRUD，没有一点其他业务在里面。

完全扯淡，不懂不要随便误导别人。

使用DTO或者Map作为参数传递都是典型的错误做法。除了工具方法，与业务逻辑相关的接口，都不应该使用DTO或者Map作为参数。

7楼说的很好，是否意味着目前我们的设计水平太低了呢，经常业务层好像没有做什么事情一样