好/坏的业务对象设计？

Question

我继承了一套业务对象，它们工作得相当好。它看起来像是基于Rockford Lhotka的CSLA框架，但有一个非常恼人的问题。当业务对象加载时，它会抛出异常。因此，如果它试图加载一些在数据库中不可用的数据，就会抛出一个异常。这是一个好的设计吗？

Answer 1

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

我断言，当你想做X的方法不能做X的时候，这就是异常的定义。

您选择如何处理该异常则是另一回事。您可以选择在代码中内部处理该异常，也可以选择将该异常的处理推迟到代码中的更高级别。

我同意，如果异常发生的时间和地点有意义的话，最好是处理它，而不是把它推迟到更高级别的代码。

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

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

1. 按预期返回对象。
2. 无法连接到数据库。
3. 找不到您希望找到的数据。

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

或者，我断言您可以创建一个带有消息字段的自定义异常，以便在其中传回发生的异常事件。强制更高级别的代码按照它认为合适的方式来处理这些情况。

在我看来，后者可以更灵活，但确实需要更高级别的代码知道它需要处理异常，这应该被很好地记录下来，以便明确一个方法可以抛出某些异常。

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

Answer 2

IMHO，异常是针对异常情况的--丢失的数据通常不是异常的，除非它位于主键或其他非空字段上。

Answer 3

这取决于数据丢失对应用程序的影响。如果应用程序在没有数据的情况下不能合理地继续运行，那么这是一个例外情况，需要例外。如果数据丢失是相对正常的(特别是如果调用者需要处理异常并继续)，那么这就是使用异常，这是一个糟糕的设计。