use*_*223 3 domain-driven-design business-logic try-catch business-rules asp.net-mvc-3
我读过 scott millett 写的《专业 asp.net 设计模式》一书，在他的示例中，他在 Validate() 方法中验证了他的业务逻辑，如果任何违反的规则被破坏，它们将被添加到集合中，并且服务层会调用一个方法该模型称为 GetBrokenRules()。
现在我还阅读了几本有关 DDD 的书籍、博客和论坛，它们说在 DDD 中对象永远不应该进入无效状态。
我见过的有关 DDD 的所有示例都会在业务规则被破坏时抛出错误，而不是传回被破坏的规则的集合。我什至下载了 scott millett 的最新源代码，他现在更改了代码，现在会抛出错误，而不是传回损坏的规则列表。我还在其他 DDD 代码示例中看到了相同的方法。
我正在与一位团队成员进行辩论，他认为抛出错误是资源昂贵的，我们不应该抛出错误，而应该像我们目前所做的那样返回一组损坏的规则。然而，通过这样做，我们传递了一个无效的对象，因为它包含不可靠的数据，并且我们只在最后检查其破坏的规则。
我只是在想其他人对这个问题的看法。一旦业务规则失败，我们是否应该立即抛出错误？如果是这样，您能强调一下这样做的优点和缺点吗？我不知道 .net 中抛出错误的资源消耗有多大，所以我不能反对这一点，但我想知道这是否也是个人意见而不是编码标准的问题。
麦克风
异常只有在实际抛出时才会昂贵。
由于您应该事先验证逻辑，因此异常应该很少且间隔很远。如果情况并非如此，那么你就做错了。
到目前为止，异常是通知模型处于无效状态的最佳机制。如果应用程序不终止，则需要显式处理它们。
使用错误集合/返回值不是一个好习惯，因为这些可能（并且很多时候）会被使用代码忽略。