好/坏的业务对象设计？答案

【问题标题】：Good/Bad business object design?好/坏的业务对象设计？
【发布时间】：2010-11-24 16:16:39
【问题描述】：

我继承了一套运行良好的业务对象。它看起来好像是基于Rockford Lhotka 的 CSLA 框架，但有一个非常烦人的问题。当业务对象执行加载时，它会引发异常。因此，如果它尝试加载数据库中不可用的一些数据，则会引发异常。这是好设计吗？

【问题讨论】：

【解决方案1】：

我最近一直在与一位同事就这个话题进行辩论。

我的断言是，您期望执行 X 的方法不执行 X 的情况正是异常的定义。

你选择用这个例外做什么是另一回事。您可以选择在代码内部处理它，也可以选择将该异常的处理推迟到代码中的更高级别。

我同意，如果在异常发生的时间和地点这样做是有意义的，而不是将其推迟到更高级别的代码，那么处理异常总是更好。

也就是说，我也相信在较低级别的代码中，将这些异常的处理推迟到较高级别的代码是有意义的。这为更高级别的代码在如何处理这些情况方面提供了更大的灵活性，并且还为更高级别的代码提供了对所发生情况的洞察力。

例如，如果您从数据库中检索数据并构建一个对象以在您的应用程序中使用，您可能会发生以下几件事：

您可以通过简单地返回一个空对象或 null 来处理异常 2 和 3，但是更高级别的代码不知道为什么它请求的信息没有返回。这将需要一些辅助模式来通知更高级别发生的事情。

另外，我断言您可以创建一个自定义异常，其中包含一个消息字段，在该字段中传递回发生的异常事件。强制您的更高级别代码在它认为合适的情况下处理这些情况。

在我看来，后者可能更灵活，但确实需要更高级别的代码知道它需要处理应该有详细记录的异常，以便其明确的方法可以抛出某些异常。

注意：我不是专家，我并不声称自己是专家，我在与我一直在讨论这个话题的同行的鼓励下分享我的观点。

【讨论】：

【解决方案2】：

恕我直言，例外是针对例外情况——缺失数据通常不是例外，除非它位于主键或其他非空字段上。

【讨论】：

【解决方案3】：

这取决于丢失数据对应用程序的影响。如果应用程序在没有数据的情况下无法合理地继续，那么这是一个例外情况，并且有必要例外。如果数据丢失是相对正常的（尤其是如果调用者需要处理异常并继续执行），那么使用异常是一种糟糕的设计。

【讨论】：