业务对象，验证和异常 [英] Business Objects, Validation And Exceptions

问题描述

我一直在阅读关于异常及其使用的几个问题和答案。似乎是一个强烈的意见，只有为例外，未处理的案件提出例外。所以这让我想知道验证如何与业务对象一起使用。

I’ve been reading a few questions and answers regarding exceptions and their use. Seems to be a strong opinion that exceptions should be raised only for exception, unhandled cases. So that lead me to wondering how validation works with business objects.

说我有一个业务对象与getters / setters对象上的属性。假设我需要验证该值在10到20之间。这是一个业务规则，因此它属于我的业务对象。所以这似乎暗示我的确认代码在我的设定者。现在我有我的UI数据绑定到数据对象的属性。用户输入5，所以规则需要失败，用户不能移出文本框。 。 UI是数据绑定到属性，所以setter将被调用，规则检查和失败。如果我从我的业务对象引发了一个异常，说这个规则失败了，那么用户界面会选择这个。但这似乎违反了例外的首选用法。鉴于这是一个设定者，你不会真的要为设定者获得结果。如果我在对象上设置了另一个标志，那意味着用户界面必须在每个UI交互之后检查该标志。

Lets say I have a business object with getters/setters for the properties on the object. Let’s say I need to validate that the value is between 10 and 20. This is a business rule so it belongs in my business object. So that seems to imply to me that the validation code goes in my setter. Now I have my UI databound to the properties of the data object. The user enters 5, so the rule needs to fail and the user is not allowed to move out of the textbox. . The UI is databound to the property so the setter is going to be called, rule checked and failed. If I raised an exception from my business object to say the rule failed, the UI would pick that up. But that seems to go against the preferred usage for exceptions. Given that it’s a setter, you aren’t really going to have a ‘result’ for the setter. If I set another flag on the object then that would imply the UI has to check that flag after each UI interaction.

那么验证如何工作？

编辑：我可能在这里使用过度简化的例子。像上面的范围检查一样可以很容易地被UI处理，但是如果valdation更复杂，如果业务对象基于输入计算一个数字，如果计算出的数字超出范围，则应重新注册。这是更复杂的逻辑，不应该在UI中。

I've probably used an over-simplified example here. Something like the range check above could be handled easily by the UI but what if the valdation was more complicated, e.g. the business object calculates a number based on the input and if that calculated number is out of range it should be recjected. This is more complicated logic that should not be in th UI.

还考虑到已输入的字段输入的进一步数据。例如，我必须在订单上输入一个项目以获得一些信息，如现有库存，当前成本等。用户可能需要这些信息作出进一步输入的决定（要订购多少单位）或可能需要按顺序以进一步验证。如果该项目无效，用户是否可以输入其他字段？要点什么？

There is also the consideration of further data entered based on a field already entered. e.g.I have to enter an item on the order to get certain informaion like stock on hand, current cost, etc. The user may require this information to make decisions on further entry (liek how many units to order) or it may be required in order for further validation to be done. Should a user be able to enter other fields if the item isn't valid? What would be the point?

推荐答案

你想深入研究 Paul Stovell 关于数据验证。他在这篇文章中一次总结了他的想法。我恰好在这个问题上分享了他的观点，我在我自己的图书馆。

You want to delve a bit in the remarkable work of Paul Stovell concerning data validation. He summed up his ideas at one time in this article. I happen to share his point of view on the matter, which I implemented in my own libraries.

保罗的话说， setter中的例外（基于一个 Name 属性不应为空）的示例：

Here are, in Paul's words, the cons to throwing exceptions in the setters (based on a sample where a Name property should not be empty) :

• 可能有时候你真的需要一个空的名字。例如，作为创建帐户表单的默认值。


• 如果您在保存之前依靠此来验证任何数据，会遗漏数据已经无效的情况。那么我的意思是说，如果你从一个空的名字加载一个帐户的数据库，不要改变它，你可能就不会知道这是无效的。


• 如果你不是使用数据绑定，您必须使用 try / catch 块编写大量代码才能向用户显示这些错误。尝试在用户填写表单时显示错误，这是非常困难的。


• 我不喜欢为非特殊的事情抛出异常。用户将帐户的名称设置为Supercalafragilisticexpialadocious不是例外，这是一个错误。这当然是一个个人的事情。


• 这样很难得到所有已经被破坏的规则的列表。例如，在某些网站上，您将看到验证信息，例如必须输入姓名，必须输入地址，必须输入电子邮件。为了表明这一点，你将需要大量的 try / catch 块。

• There may be times where you actually need to have an empty name. For example, as the default value for a "Create an account" form.
• If you're relying on this to validate any data before saving, you'll miss the cases where the data is already invalid. By that, I mean, if you load an account from the database with an empty name and don't change it, you might not ever know it was invalid.
• If you aren't using data binding, you have to write a lot of code with try/catch blocks to show these errors to the user. Trying to show errors on the form as the user is filling it out becomes very difficult.
• I don't like throwing exceptions for non-exceptional things. A user setting the name of an account to "Supercalafragilisticexpialadocious" isn't an exception, it's an error. This is, of course, a personal thing.
• It makes it very difficult to get a list of all the rules that have been broken. For example, on some websites, you'll see validation messages such as "Name must be entered. Address must be entered. Email must be entered". To display that, you're going to need a lot of try/catch blocks.

这里是替代解决方案的基本规则：

And here are basic rules for an alternative solution :

1. 无效的业务对象没有任何问题，只要你不试图坚持下去。


2. 任何和所有破碎的规则都应该从业务对象中检索出来，以便数据绑定以及您自己的代码可以看到是否存在错误并适当地处理它们。

这篇关于业务对象，验证和异常的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！