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

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

评论

22 楼 logicgate 2009-05-04  

赞成异常的说法。Martin Fowler的重构一书里面也提到，"Long parameter list"是一种不好的方法。

一般上对于业务性不是很强，参数数目可能变动的方法，我倾向于使用DTO或者Map。反之则使用直传。

21 楼 holan 2009-05-04  

抛出异常的爱 写道

downpour 写道

抛出异常的爱 写道

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

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

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

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

错误的标准在哪里能下载到?
跪球 : 传送门.

PS:如果没有网络版给,讲一下大体上的方式可以么

PS2:
如果不用map 是怎么防止类暴炸的?
我可以作到参数套参数...
把类与参数 数量减少到一定的数量
但项目组里大多数人
不会喜欢作这么图劳无功的事
所以推行起来可能会有很大障碍.

我觉得还是不用map的好，用map传，不如做一个内部类来传参数。
map让我有重回php的感觉

20 楼 抛出异常的爱 2009-05-04  

downpour 写道

抛出异常的爱 写道

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

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

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

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

错误的标准在哪里能下载到?
跪球 : 传送门.

PS:如果没有网络版给,讲一下大体上的方式可以么

PS2:
如果不用map 是怎么防止类暴炸的?
我可以作到参数套参数...
把类与参数 数量减少到一定的数量
但项目组里大多数人
不会喜欢作这么图劳无功的事
所以推行起来可能会有很大障碍.

19 楼 VonNeumann 2009-05-04  

october731 写道

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

你的方法发挥到极致就是Hibernate的criteria了吧
这样做挺好 用method chain 还能有默认参数的效果

18 楼 downpour 2009-05-04  

jonson 写道

凤舞凰扬 写道

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

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

你错了，并不是所有的功能与服务都体现在UI上的。设计系统是一个复杂的过程，可以采用很多种方式。现在的很多情况下，UI驱动设计成为了很重要的一种工作方法。不过真正的Web Service，可能要涉及到系统间接口，针对UI的接口等各种各样的考虑。

17 楼 jonson 2009-05-03  

凤舞凰扬 写道

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

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

16 楼 hatedance 2009-05-03  

1 层间同名函数，我觉得可以做一个基于反射的通用的函数。比如:
  object invoke(String methodName,object[] params);

2 有些crud的函数的确是无法避免在dao层就实现了的。但是尽量如果你采用ddd，很多逻辑都实现在domain层了，ws层的确只是转发而已，和buiness层采用同一个接口，以确保同步。

15 楼 williamou 2009-05-03  

我的理解：
form层：表现层，负责用户交互逻辑，调用逻辑层接口执行业务操作。
biz层：逻辑层，系统对外提供的业务操作接口都在上面。
ws层：只不过biz层的一个扩展，提供远程调用。应该与biz层一致，至少是对得上的。

由于biz层和ws层其实都是提供同一套业务接口，"同名的方法"就是很正常的事。

参数的问题好像又是另一个问题了
"GetAllEmp（string name，bool sex, string address, int age）"应该是逻辑层上一个查询接口吧。除了是实在业务上有需要，如提供一个 get A by B's ID这样一个方法，才会可能有 getAByB(String BID)这样的接口，不然一般可以考虑做成一个接受通用的查询条件的查询方法，如search(SearchCondition[] conditions)。 逻辑层上提供这样的接口仿佛更适合。

14 楼 steeven 2009-05-02  

这个问题很有意思, 记得java上前几年在讨论要不要把entity往前传. 现在似乎不用讨论了.

EJB3.1的一个想法就是把EJB/Web打包成一个war, 而ejb3.0的想法是pojo, 用annotation去简化. 其中一个bean上可以同时加上@Stateless, @Webservice, 就是说没有必要再去人为加个ws层, 这些工作让框架去搞定.

用netbeans的向导生成一个ejb应用看看就知道了, 简单快速. JAVA框架正在回归原始.
JSR295/303 will change our life


java行业里面形而上学的无聊结构太多了, 看看domino和sap, 简单实用.

13 楼 hankesi2000 2009-05-02  

我认为目前很多项目中都存在这样的一个情况：使用一个通用的模板，模板告诉你这块需要写什么，那就写什么；然后由于各种情况的出现，如项目开发时间、技术能力等，导致项目没有根据需要发挥出模板的功能；接着项目做大了，更改难度大了，就这样一直开发下去了。。。
楼主的项目我认为就是这样的一个例子。就问题而言，怎么解决，还需要根据业务而定

12 楼 yimlin 2009-05-02  

楼主的问题在于ws层其实没有特别意义，仅仅起到了调用转发。
所以还是要回到最初的问题：设立三层的目的何在？是为了分层而分层还是有额外目的？若有额外之目的，则实践中为何为出现变形？是否架构最初试图解决的问题而实际并不存在？
明白这些问题就可以做相应调整。
比如：
A.ws层和biz层物理上合并；form层直接访问biz层；
B.WS层和BIZ层逻辑上合并，ws层提供接口，biz层以空接口继承ws层，变成两个接口一个实现；运行期，ws层提供自动代理，将调用转发到biz层的实现上；并以此为原则，非此为例外。

11 楼 whaosoft 2009-05-01  

这不好说 其实哪个框架都有好有坏的
还有如果你不是设计人员 你就要服从那个框架要不没法干活了 是吧

10 楼 魔力猫咪 2009-05-01  

看看《领域驱动设计》吧。理论上所有的业务都应该存放到领域对象和服务中。所谓的业务层只是对业务流程进行组合。

9 楼 guoery 2009-05-01  

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

8 楼 downpour 2009-05-01  

抛出异常的爱 写道

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

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

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

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

7 楼 魔力猫咪 2009-05-01  

凤舞凰扬 写道

   楼主列的问题是大多数系统存在的问题，也就是常见的杠铃型，两头大中间小（业务层与表现层之间的接口层，比如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，没有一点其他业务在里面。

6 楼 凤舞凰扬 2009-05-01  

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

5 楼 wl95421 2009-04-28  

参数接口+Adapter模式

4 楼 sslaowan 2009-04-28  

抛出异常的爱 写道

october731 写道

公司的项目分层，是公司自己搭建的框架，分为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
}

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

3 楼 snipercc 2009-04-28  

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