如何将错误和其他消息从 DAL / 业务层向上传递到 UI 层？

Question

很多资源都说要让错误从较低层“冒泡”，但我不确定如何在我的应用程序中实现这一点。我是否需要为验证或其他错误创建一个单独的实用程序类并在每一层监听它？

例如，如果用户输入一个电子邮件地址并且只允许唯一的电子邮件地址，我假设我会在业务层中检查这一点。当我从 UI 调用业务逻辑时，我是否只在我的业务类中包含错误/错误消息的输出参数。我是否应该将已处理的异常与业务规则异常一样对待？

这是一个 BLL 代码示例：

public class user()
{
    public void Save(UserObject myUser, out bool result, out string resultMsg )
    {
    }

    OR

    string saveResultMsg;

    public bool Save(UserObject myUser)
    {
        saveResultMsg = "bad data whatever";
        return false;    

    }

}

Answer 1

这实际上取决于您要做什么，理想情况下，异常应该用于异常情况，而不是控制流程。

我是内部验证过程的粉丝，并且拥有布尔“保存”方法。如果为 false，您可以检查“验证异常”属性以查看哪些规则违反了条目以不保存。

如果需要，您也可以使用异常，只要确保使用适当的异常类型而不是基 Exception 类。

Answer 2

例如，如果用户输入电子邮件 地址和唯一的电子邮件 地址是允许的，我假设我 会在业务中检查这一点 层。当我调用业务时 来自 UI 的逻辑，我是否只包括 我的业务中的输出参数 错误/错误消息的类。 我是否应该处理已处理的异常 和业务规则例外一样吗？

我更喜欢提供应用层可以用来检查唯一性的方法，然后在业务层中再次检查，如果调用者试图保存重复值，则抛出异常。

除非这两个数据库调用确实导致性能问题，否则我通常会发现separating the command and query logic 是worth it。

（我的建议是针对业务应用程序，其中大多数具有适度的性能要求。还有许多其他类型的软件，这种方法并不总是或永远不适合。）

Answer 3

您始终可以为您的应用程序创建自定义异常，让您的业务层在发生错误时抛出这些异常，然后让您的 UI/消费者正确处理这些自定义异常。

在你的情况下，我可能会这样做：

[Serializable]
public class EmailValidationException : Exception
{
    // overriden constructors would go here

    private List<string> _validationMessages = new List<string>();

    // store your validation exception messages in a collection
    public ReadOnlyCollection<string> ValidationMessages 
    {
        get
        {
            return _validationMessages.AsReadOnly();
        }
    }
}