我一直在阅读一些有关异常及其使用的问题和答案。似乎有一种强烈的观点认为，仅应针对异常、未处理的情况提出异常。因此，这让我想知道验证如何与业务对象一起工作。
假设我有一个业务对象，其中包含对象属性的 getter/setter。假设我需要验证该值是否在 10 到 20 之间。这是一条业务规则，因此它属于我的业务对象。所以这对我来说似乎意味着验证代码进入我的设置器中。现在我将 UI 数据绑定到数据对象的属性。用户输入 5，因此规则需要失败，并且不允许用户移出文本框。 。 UI 数据绑定到属性，因此将调用 setter、检查规则并失败。如果我从业务对象中引发异常，表明规则失败，UI 会接收到该异常。但这似乎违背了异常的首选用法。考虑到这是一个二传手，你实际上不会得到二传手的“结果”。如果我在对象上设置另一个标志，则意味着 UI 必须在每次 UI 交互后检查该标志。
那么验证应该如何进行呢？
编辑：我可能在这里使用了一个过于简化的示例。像上面的范围检查这样的事情可以通过 UI 轻松处理，但是如果验证更复杂怎么办？业务对象根据输入计算一个数字，如果计算出的数字超出范围，则应拒绝该数字。这是更复杂的逻辑，不应该出现在 UI 中。
还考虑根据已输入的字段输入进一步的数据。例如，我必须在订单上输入一个商品才能获取某些信息，例如现有库存、当前成本等。用户可能需要此信息来决定进一步输入（例如要订购多少单位），或者订单中可能需要此信息以便进一步验证。如果该项目无效，用户是否应该能够输入其他字段？重点是什么？
你想深入研究一下保罗·斯托维尔 http://www.paulstovell.com/关于数据验证。他曾一度总结自己的想法本文 http://www.codeproject.com/KB/cs/DelegateBusinessObjects.aspx。我碰巧同意他对此事的看法，我在我自己的图书馆 http://salamanca.nourysolutions.com/road/index.php?post/2008/08/26/Inside-the-libraries-I-%3A-Data-Rules.
用 Paul 的话说，这里是在 setter 中抛出异常的缺点（基于一个示例，其中Name属性不应为空）：
- 有时您可能实际上需要一个空名称。例如，作为默认值“创建一个帐户” form.
- 如果您在保存之前依赖于此来验证任何数据，您将错过数据已经无效的情况。我的意思是，如果您从数据库加载一个空名称的帐户并且不更改它，您可能永远不知道它是无效的。
- 如果您不使用数据绑定，则必须使用以下内容编写大量代码
try/catch块向用户显示这些错误。当用户填写表单时尝试在表单上显示错误变得非常困难。
- 我不喜欢为非异常的事情抛出异常。用户将帐户名称设置为“超级加州脆弱性Expialidocious”不是异常，而是错误。当然，这是个人的事情。
- 这使得获得所有已被违反的规则的列表变得非常困难。例如，在某些网站上，您会看到验证消息，例如“必须输入姓名。必须输入地址。必须输入电子邮件”。为了显示它，你将需要很多
try/catch blocks.
以下是替代解决方案的基本规则：
- 拥有无效的业务对象并没有什么问题，只要您不尝试保留它。
- 任何和所有损坏的规则都应该可以从业务对象中检索，以便数据绑定以及您自己的代码可以查看是否存在错误并进行适当的处理。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
