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

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

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

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

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

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

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

对于一个具备强类型特征的语言来说，抛弃强类型的语法检查肯定不是最佳实践。更何况，对于WebService来说，使用Map作为参数进行传递完全就是不负责任的做法。从哲学上说，一个对外的接口，必须让调用者有明确的契约认识。对于把Map作为参数进行传递的做法，对于调用者而言，既不知道你Map中到底有哪些key值，又不知道你Map中每个key值所包含的数据类型和数据格式，请问这个接口还有什么意义？事实上，我见到过无数这样的接口，甚至连Java Doc都没有，让调用者一头雾水，害人害己。

至于使用DTO作为参数进行传递，事实上也早已经被证明是一个反模式。DTO这种模式很早就不应该存在了，除非在一些系统与系统之间的接口调用时，需要用到DTO（比如Ajax进行远程调用，返回的可能是一个DTO）。

正确的做法，应该从系统架构的实际出发，设计出最符合系统间服务调用的契约。对于典型的增删改操作，参数只需要直接与entity挂钩即可。对于查询操作，就有点麻烦，可能需要根据实际情况的不同，设计出来多种不同的函数契约，至于参数，不超过5个情况下，直接写清楚即可，对于超过5个的情况，就需要设计一个完整的能够表达契约约定的类来进行表述。

在biz层直接写HQL语句最简练，业务做细了或以后扩展都简单。
否则dao的方法参数总要改。

其实这些问题，都是由于分层过细引起的。
分层确实也是个值得探讨的问题。本身分层就是希望低耦合，以便于将来修改，但是他只适合于逻辑算法的变化，并不适合于接口的变化或者数据结构的变化，包括参数的变化。当发生接口或者参数的变化时，反而使得增个变更变得更加复杂。
如果想因此，放弃分层，却发现这种方式，会放纵程序员，最终也使得维护比较麻烦。
我们是自己做开发平台的，因此接口的维护是可以配置的。至于分层是由平台提供。但是从原理来说，也存在这种接口变化问题。仔细分析话，我们使用Map来存储接口参数的，当然这个Map会一层层传下去，包括最后回传的时候，也是一层层再传回来。
这样不光参数是可变的，而且返回值也是可以多个，而且是可变的。
你要说性能，其实也是非常快的。因此这个Map只生成一次，数据只在一个地方存储。如果用原始方式实现，将数据放到类中的属性来实现，要多次复制数据。这个不光影响速度而且也消耗内存。

造成需要Map或者DTO的原因有三个，一个是领域划分不清，业务对象没有承担应有的职责。二是Java语言的静态性限制了走捷径。三是的确少部分调用特别是从WEB层传递下来的操作，的确需要太多的参数。然而其实在第三种情况下用DTO也会比Map要好些，它毕竟是一个参数对象，除了getter/setter还可以加入一些特定层次需要的一些method。很多这类方法加在这种所谓的Dto中，要比加在Util中更自然，更舒服。
如果是开发框架，Map的用途是很大的，但不建议直接暴露给App的开发人员。在开发App的过程中，Map还是能不用就不用就不用吧。

对于查询, 直接让客户传HQL进来吧, 或者可以很容易翻译成HQL的string.
反正后台也不过是简单拼装一下. 记得用varargs来做参数. 这样接口就完美了.

关于查询结构, hibernate里面好像有个对象来表达复杂的查询条件的.

不同的层次应该有不同的数据对象，哪怕他们的实体都是一个，但职责角色肯定是不同的。这是我判断是否需要划分层次的一个原则，这时候在不同层次进行传递才需要DTO。

如果模块简单到各层次对象结构都一样，那说明职责上就不需要，起码不那么需要划分多一个层次，设计时就得考虑。

而对于系统中这种简单模块，这时候为了保有整个系统层次划分的一致性，可以写个通用的Adaptor转发一下，直接跳过不需要的层次。

这是我的办法。^^

   如果系统真的很简单，项目也很小。我个人并不反对这样做，只是希望猫咪理解为何要分层就可以了。