|
锁定老帖子 主题：分层结构的方法的参数的传递
精华帖 (1) :: 良好帖 (3) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2009-05-07
凤舞凰扬 写道 抛出异常的爱 写道 对于契约封装这种方式来说很正解 但我认为尽量减少理解困难角度来讲 map可以作为ibatis的参数减少dao与mapping的代码 map可以当作(非业务必须)参数的页面显示用的容器,减少action的参数总数量. 这两点对于一般服务性业务来说(非平台软件)还是有必要的 其实downpour的观点并非不能用map，而是不应该在对外服务级接口使用。Map作为参数，最合适的是在功能级的接口参数，例如工具方法或者不确定变量等，其实对于不确定变量参数内容，也应该是通过类Map的context对象方式传递，而不是Map本身，因为Map是无法序列化，并且无法知道其内部对象是否支持序列化，这对于网络应用（包括web）是潜在的风险的。 补充得太完美，每句都是我想说的。 |
| 返回顶楼 | |
|
发表时间：2009-05-07
如果是手工编码开发，那么按照面向接口编程的原则，参数在接口中是确定的。如果需要动态的话，那么用接口类的Object来进行传递，返回值也是这样考虑。
但由于我们采用代码自动生成方式的，因此不需要手写编写程序来处理Map中的数据。因此Map还是最灵活一种方式。 |
| 返回顶楼 | |
|
发表时间：2009-05-07
最后修改：2009-05-07
downpour 写道 抛出异常的爱 写道 对于契约封装这种方式来说很正解 但我认为尽量减少理解困难角度来讲 map可以作为ibatis的参数减少dao与mapping的代码 map可以当作(非业务必须)参数的页面显示用的容器,减少action的参数总数量. 这两点对于一般服务性业务来说(非平台软件)还是有必要的 抛同学，dao中使用Map做参数当然是没有问题的，难道你不把dao作为一个很工具的层面去看吗？在我看来，一切DAO和工具类没什么两样，除了HQL和参数以外，应该没有其他业务了。 但是在业务逻辑层，我是坚决反对使用Map或者毫无意义的DTO作为参数进行传递的，因为它实际上破坏的接口的契约含义，使得制定接口的意义变得几乎没有。 至于谈到WebService的接口设计，又是另外一回事情了，可能连entity都不适合作为参数进行传递。这个时候，函数签名的设计更加重要。 不知道你是否能同意我的观点。 同意你的观点但在本例上面 的问题是对 多参数的优化 多参数的方案: 第一条我主张使用某个 有逻辑意义的bean来放数据 这样最好 但这个世界上有最好 就有作不到 所以第二我提出来直接放数值 对于指定的功能可能更要合适一些 因为一眼就能明白这个方法的需要 当然这样就出了楼主的问题 参数过多 一般的好的实践是整合参数 把对应的参数放入对应意义bean中 使数据总量再减少... 当然这样作的好处可以看的见 但实际编程人员不这样认为 更有可能 变的更不可控制. 所以实际推广难度非常之大 不得已使用了更好推广的方式 恶心的map 为了防止 map 中的 key 值拼写问题 用了另一个恶心方工 那就是:接口中存放的静态变量 用这种静态变量作为key 当然使用dto也可以 但上个项目中爆发的dto 心有余忌.... 大多数时候否定此方案. 当然对于平台开发来说可能这是不好的实践 但在服务业务开发团队来说是可操作的的. 对于我这种无神论者 就是好用的规则那是好规则 无法被团队成员接受的规则 踢到一边去. 不必一上来就要求别人用最佳实践. 而是先把好上手的实践普及 再考虑不好上手的最佳实践 楼上反对我用map都是从平台角度 上说的我非常理解. 是好东西. 但如果真的需要我会设计成非map类的. 现在先这样吧. |
| 返回顶楼 | |
