验证布尔属性
我觉得问这个问题有点尴尬。不过，似乎在其他地方找不到它的描述...
比如说，我们有一个 Web 服务方法 StoreNewItem(Item item)，它接受包含该项目的所有属性的数据契约。 我们将把这个新项目插入数据库中。 有些属性是强制性的，有些是布尔值。
我们是否应该验证传入的数据，即验证必填字段是否确实具有有效数据，还是应该由调用 Web 服务的客户端负责？
如果是，如何处理布尔属性？客户端很可能会忽略它们，并且它们将在数据库中存储为 false，因为我们无法知道它们是否设置为 false 或者只是被客户端忽略/遗忘。
使用具有 True、False 和 Empty 的枚举而不是 bool 作为这些强制属性的类型是否是有效的选项？ 或者这根本不是我们的问题？
欢迎所有想法！
I feel abit embarrassed asking about this. Cant seem to find it described anywhere else though...
Say, we have a webservice method, StoreNewItem(Item item), that takes in a datacontract with all the properties for the item.
We will insert this new item in a database.
Some of the properties are mandatory, and some of these are boolean.
Should we validate the incomming data, i.e. verify that the mandatory fields actually have valid data, or should this be the responsibility of the client calling the webservice?
If yes, how to handle the boolean properties? The client may well ignore them, and they will be stored as false in db, as we have no way of knowing if they where set to false or just ignored/forgotten by the client.
Is it a valid option to use an enum with True, False and Empty instead of bool as a type for these mandatory properties?
Or is this simply not our problem?
All thoughts are welcome!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
您可以使用 Web 服务完全支持的可空布尔值（bool？）来代替枚举。
恕我直言，您的检查逻辑至少应该位于数据库中，它可以将错误转发到服务层（反过来应该引发故障）。不过，我也会在服务级别拥有它，以便可以在访问数据库之前引发错误（验证也是业务层的一部分）。在 UI 中也有它很好，但不是强制性的。
永远不要假设您的客户向您发送了有效数据。
Instead of enums, you can use nullable booleans (bool?) which are fully supported by web services.
IMHO Your checking logic should at least be in the db which can forward the error to the service layer (which in turns should raise a fault). I'd have it at the service level too though so that the error can be raised before hitting the db (validation is part of the business layer too). Having it in the UI too is nice but not mandatory.
Never assume your clients send you valid data.
一定要验证数据。恶意实体可以轻松复制您的客户。
Definitely validate the data. Malicious entities could easily replicate your clients.
这取决于您的业务规则。
如果您希望允许用户不传递某些参数但希望它们获得默认值，则可以使用可选参数
，或者如果您希望允许用户不使用空值传递所有参数，则可以使您的服务获得可为空值（如果您的业务规则允许的话）
一般来说，您应该始终在服务端验证数据，并在验证失败的情况下返回服务故障数据合同
更多信息
http://msdn.microsoft.com/en-us/library/ms752208.aspx
it depends by your business rule.
you could use optional parameter if you want to allow the use not to pass some parameters but you want them got a default value
or you can make your service get nullable value if you want allow the user not to pass all the parameter using null value(if your business rule can allow that)
In general you should always validate the Data on the Service side and return a service fault data contract in the case the validation fails
more info at
http://msdn.microsoft.com/en-us/library/ms752208.aspx
如果没有外部第三方访问 Web 服务（仅在内部使用），您可以不用在服务中进行验证。但就我个人而言，我不会这样做；向服务发送错误数据太容易了。另外，那么您将必须在所有客户端上复制所有验证逻辑。因此，我认为在服务中进行验证是必须的。
至于布尔值，您可以使用可空布尔值 (
bool?)。If no external third party will be accessing the web service (used only in-house), you can get away with not validating in the service. Personally, I wouldn't do that though; it's too easy to have bad data sent to the service. Plus, then you would have to duplicate all the validation logic across all clients. So validating in the service is a must in my opinion.
As far as booleans, you can use nullable booleans (
bool?).