在什么时候对参数进行验证

wolf_awp

浏览: 55174 次
性别:
来自: 上海

最近访客更多访客>>

cloudjie

baole323

纯白的黑

FishBoy

博主相关

博客

微博

相册

留言

关于我

文章分类

社区版块

存档分类

博客分类：

java基础

为了保证函数运行的正确性，在函数的开始一般要对参数的正确性进行判断，如果函数间相互进行调用的时候，可能会出现多次对同一个参数的正确性进行验证，出现代码冗余。
比如在Action的一个函数里面调用一个Service的方法，参数验证位置有三种情况：

1、在Service的函数里面
2、在Action里调用Service的方法前
3、在两个函数里面都对参数进行验证（肯定会有代码冗余）

如果一个函数要求参数不能为空或是空字符串，在函数的里面应该就是这样的：

public void doSomething(String foo) {
	if (null == foo || "".equals(foo.trim())) {
		return;
	}
	// some code
}

在另一个函数里面调用到了上面的方法：

public void doAnything(String foo) {
	if (null == foo || "".equals(foo.trim())) {
		return;
	}		
	doSomething(foo);
    // some code
}

这样的话验证参数的代码就重复了。

个人认为，在Service层里面可以不进行参数的验证，假定参数都是正确的。而是在调用Service层的方法之前，先对要传入的值进行验证，正确了才能调用相应的方法。

问题核心就是，是要在一个函数里面进行参数验证，还是在调用函数前对参数进行验证。

大家平常怎么写的，相互参考下。

分享到：

通过位与运算判断奇偶数 | Eclipse console 中文乱码解决方法

2011-05-20 00:08
浏览 4580
评论(44)
论坛回复 / 浏览 (44 / 14119)
分类:编程语言
查看更多

24 楼 xieyanhua 2011-05-21

<div class="quote_title">skzr.org 写道</div>
<div class="quote_div">
楼主这个困惑不是你一个人困惑阿，呵呵 估计每个开发的都困惑过：严格的规范说每一个地方都要验证，但是实际上很多地方的验证都是重复的“冗余”。 每个代码的上下文都是不一样的，所以没有最好的，只有适合自己的实践。 在我的系统中，最佳实践：
<ul>
<li>每一需要验证的方法，都把前置条件写入到方法注释中——必须的</li>
<li>
dao不做任何验证，认为输入的参数都是验证过了的</li>
<li>service层如果是外部接口，那么做验证，反之认为都是合法的（一般调用者就是Action，或者其他service）</li>
<li>
action必须做验证，并提供友好的反馈给调用界面</li>
</ul>
现在在构建一个平台，感觉和做小项目不一样：service层如果是外部接口，那么做验证，反之认为都是合法的（一般调用者就是Action，或者其他service）
这里service基本都是需要对外的，也就是这一条变成了所有的service都要做验证。
最终：除开dao不做验证外其他的都要做验证，因为dao是系统内部使用，外部系统无法访问。
 
</div>
和我的观点一样，我也都是这么做，比如一个比如以前的jsp+acton+service+dao的系统，因为就一个独立的系统，没有提供对外的接口（也不涉及远程调用），所以service和dao都不做校验，只做业务逻辑的校验，这两层都是我们系统内部调用，仅供action调用，所以我们的校验都放在jsp和action；
 
还有别的系统中，部分service的接口会提供出来，供其他系统调用，或者webservice等，出了我们系统调用外，还有别的系统在调用，所以这个时候，这个webservice接口就要做校验了；加入涉及远程RMI调用的，我们也会做校验；因为rmi调用不同于本地调用，本地调用不存在参数丢失或修改的问题，而远程调用，有可能网络丢包或受到干扰造成数据发生了变化，这些都有可能，所以这些我们也会校验，比如以前用ejb时，在ejb中的所有方法，都会做检验。

23 楼 xieyanhua 2011-05-21

nianien 写道

一般来说，如果你是写服务，供其它客户端调用，那么你完全就可以不必进行参数校验
你所需要完成的是在参数正确的情况下保证逻辑的正确性
错误的参数的时候不需要保证程序的正确性？
况且你也不知道客户端是打算如何处理错误的参数
也许它是返回一个默认值，或者抛出异常，你不能也不必替客户端做决定
客户端怎么处理错误的参数，那是客户端的事情，但是返回什么数据则是服务器端得事情，这也没有提客户端做决定。
而参数的校验则由客户端进行校验
我是倾向于服务器端做校验，因为你不能保证每个客户端的程序都是很细心的，按你的要求去做，还有一个就是，你不校验，有的东西，可能会对系统照成危害，或者数据不正确等。校验不校验，关键要看提供给客户的服务的重要性，参数对系统的影响，比如让一个没有写权限的客户端调用了，却能实现。

楼主只是说什么时候需要对参数进行校验，不只是空或非空校验，也有包括一些逻辑校验，比如扣款是金额是否足够。仅仅是举例。

22 楼 xieyanhua 2011-05-21

wolf_awp 写道

我认为参数的正确性检测，应该由调用方进行，如果不正确，就不能调用相应的函数。一个函数可以假定参数是正确的进行处理。这样即可以保证参数的正确性又没有代码冗余。

请问你如何保证客户端传递给你的一定是正确的，只有一个程序负责调用，你可以要求，如果很多地方都调用你的service，你怎能保证所有客户端都按你的要求提供了正确的数据呢？

21 楼 fflame 2011-05-20

同意private的不验证，public的验证……

20 楼 nianien 2011-05-20

wolf_awp 写道

1、在Service的函数里面
2、在Action里调用Service的方法前
3、在两个函数里面都对参数进行验证（肯定会有代码冗余）

如果一个函数要求参数不能为空或是空字符串，在函数的里面应该就是这样的：

public void doSomething(String foo) {
	if (null == foo || "".equals(foo.trim())) {
		return;
	}
	// some code
}

在另一个函数里面调用到了上面的方法：

public void doAnything(String foo) {
	if (null == foo || "".equals(foo.trim())) {
		return;
	}		
	doSomething(foo);
    // some code
}

这个问题我也考虑过很久
一般来说，私有方法肯定不需要参数合法性校验的
而对于公开方法，那看你的服务声明了
一般写方法，都会提供相应的API文档，里面会表明你是不是进行参数校验
如果为空时是直接返回还是抛异常

一般来说，如果你是写服务，供其它客户端调用，那么你完全就可以不必进行参数校验
你所需要完成的是在参数正确的情况下保证逻辑的正确性
况且你也不知道客户端是打算如何处理错误的参数
也许它是返回一个默认值，或者抛出异常，你不能也不必替客户端做决定

而参数的校验则由客户端进行校验

19 楼 skzr.org 2011-05-20

楼主这个困惑不是你一个人困惑阿，呵呵 估计每个开发的都困惑过：严格的规范说每一个地方都要验证，但是实际上很多地方的验证都是重复的“冗余”。 每个代码的上下文都是不一样的，所以没有最好的，只有适合自己的实践。 在我的系统中，最佳实践：
<ul>
<li>每一需要验证的方法，都把前置条件写入到方法注释中——必须的</li>
<li>
dao不做任何验证，认为输入的参数都是验证过了的</li>
<li>service层如果是外部接口，那么做验证，反之认为都是合法的（一般调用者就是Action，或者其他service）</li>
<li>
action必须做验证，并提供友好的反馈给调用界面</li>
</ul>
现在在构建一个平台，感觉和做小项目不一样：service层如果是外部接口，那么做验证，反之认为都是合法的（一般调用者就是Action，或者其他service）
这里service基本都是需要对外的，也就是这一条变成了所有的service都要做验证。
最终：除开dao不做验证外其他的都要做验证，因为dao是系统内部使用，外部系统无法访问。

18 楼 kulinglei 2011-05-20

建议每次调用都校验，你一个人调用还可以，但多个人调用时，鬼知道你写校验了吗？如果写了，校验的完整吗？说代码冗余，你可以把相同的抽象出来单独放啊。我一般都做校验

17 楼 kjj 2011-05-20

一个原则吧,你在不能保证调用你的外围都会验证之前,还是自己验吧,不然npe会像幽灵一样纷至沓来........................

16 楼 codeincoffee 2011-05-20

1. 尽量用apache的StringUtils.isBlank()。

2. 好的程序员即便过单行道都会左右环顾的，这种“冗余”比起安全性来说算不上什么，所以我认为都需要验证。

15 楼 ppgunjack 2011-05-20

进公司刷卡，但一般内部就不刷卡了
但你如果进内部机房可能还需要刷卡
没定势的
关键是如果参数错了会导致异常，最好有参数内容打印
离输入端越近越需要校验

14 楼 liu.anxin 2011-05-20

又到架构跟规范的口水里面来了

13 楼 liu.anxin 2011-05-20

与其他业务逻辑有关联的, 去 service 校验, 其他的在去 service 之前校验. 习惯多用公共类就行了

12 楼 TheMarine 2011-05-20

这里你们的前提都是都是所有代码都是你们自己开发。如果是分组开发的，写action的时候能保证写service那位写了验证？写service的能保证写action帮你写好了验证？结果是大家都要写。当然不沟通的情况是没有的，但是我想说的是方法需要对自己负责，而不是把这种风险让别人帮你规避。因为对自己负责是百分百健壮，另外的就不一定。所有的方法加上参数验证就是对自己负责。case1,调用方没有验证，在被调用方验证了，ok，被调用方代码的自我保护工作了。case2，被调用方没有验证，调用方验证，那么调用方的自我保护工作了。除非一个验证都没写。考虑到2者得自我保护，代码冗余问题显得不那么重要。套用代码大全里的说法，开车的人不但不能撞人，主要还不能被撞啊。

11 楼 15210494746 2011-05-20

woaiwofengkuang 写道

个人认为，在action中一般只验证用户输入的正确性。而在service中应该验证这个参数是否满足业务需要。
比如说一个日期，在action中只要验证这个传进来的参数是否日期类型。而在service中要验证这个日期是否是未来5天内的一个日期值。
当然了只举例。

觉得说的挺清楚了，如果是输入的信息的合法性验证。建议你放在BaseAction中（当然也可以不叫baseAction）,放在控制层的自定义父类中做有很多好处，很多时候在具体的子类中不用重复的验证了。当然仅限于数据的合法性。

而在service层得验证，则是你业务需求的验证。为了是防止你业务逻辑出现错误~

所以我觉得对参数的验证，要看是什么类型的验证。

10 楼 wolf_awp 2011-05-20

woaiwofengkuang 写道

我认为这样也是合理的，虽然多次验证，但验证是内容是不一样的，也没有代码冗余。

9 楼 wolf_awp 2011-05-20

kjj 写道

这怎么能说重复呢,除了dosomthing调用foo之外,说不定其他代码也调用呢

其他代码调前，也是要先进行参数验证的。

8 楼 szcs10138456 2011-05-20

楼主你说的是正确的做法

7 楼 TheMarine 2011-05-20

这种问题通常是防御式编程，写service的能保证写action的帮你验证？再说都叫service了，未必只有action才调用，可能有其他客户端呢。

6 楼 kjj 2011-05-20

这怎么能说重复呢,除了dosomthing调用foo之外,说不定其他代码也调用呢

5 楼 woaiwofengkuang 2011-05-20

发表评论

您还没有登录,请您登录后再发表评论

最近访客更多访客>>

博主相关

文章分类

社区版块

存档分类

最新评论