如何使用MVP将服务层消息/错误传递给更高层？

我目前正在从UI编写ASP.Net应用程序.我正在实施一个MVP架构,因为我厌倦了Winforms,并希望能够更好地分离关注点.

因此,使用MVP,Presenter处理由View引发的事件.这是我用来处理用户创建的一些代码:

public class CreateMemberPresenter
{
    private ICreateMemberView view;
    private IMemberTasks tasks;

    public CreateMemberPresenter(ICreateMemberView view) 
        : this(view, new StubMemberTasks())
    {
    }

    public CreateMemberPresenter(ICreateMemberView view, IMemberTasks tasks)
    {
        this.view = view;
        this.tasks = tasks;

        HookupEventHandlersTo(view);
    }

    private void HookupEventHandlersTo(ICreateMemberView view)
    {
        view.CreateMember += delegate { CreateMember(); };
    }

    private void CreateMember()
    {
        if (!view.IsValid)
            return;

        try
        {
            int newUserId;
            tasks.CreateMember(view.NewMember, out newUserId);
            view.NewUserCode = newUserId;
            view.Notify(new NotificationDTO() { Type = NotificationType.Success });
        }
        catch(Exception e)
        {
            this.LogA().Message(string.Format("Error Creating User: {0}", e.Message));
            view.Notify(new NotificationDTO() { Type = NotificationType.Failure, Message = "There was an error creating a new member" });
        }
    }
}

我使用内置的.Net验证控件完成了主表单验证,但现在我需要验证数据是否足以满足服务层的标准.

假设以下服务层消息可以显示:

电子邮件帐户已存在(失败)

引用用户输入不存在(失败)

密码长度超过数据存储允许的长度(失败)

会员创建成功(成功)

我们还要说,UI无法预期的服务层中会有更多规则.

目前,如果事情没有按计划进行,我正在让服务层抛出异常.这是一个足够的策略吗？这段代码对你们有异味吗？如果我写了这样的服务层,你会不得不编写以这种方式使用它的Presenters吗？返回代码似乎太旧了,bool只是没有足够的信息.

不是由OP编辑:合并后续评论,由OP发布为答案

Cheekysoft,我喜欢ServiceLayerException的概念.我已经有一个全局异常模块用于我不期望的异常.你觉得让所有这些自定义异常变得单调乏味吗？我认为捕获基础Exception类有点臭,但不确定从那里取得进展.

tgmdbm,我喜欢在那里聪明地使用lambda表达式!

感谢Cheekysoft的后续行动.因此,如果您不介意用户显示单独的页面(我主要是Web开发人员),如果不处理异常,我猜这将是策略.

但是,如果我想在用户提交导致错误的数据的同一视图中返回错误消息,那么我是否必须在Presenter中捕获异常？

以下是Presenter处理ServiceLayerException时CreateUserView的样子:

对于这种错误,最好将它报告给同一个视图.

无论如何,我认为我们现在超出了我原来问题的范围.我会玩你发布的内容,如果我需要更多详细信息,我会发布一个新问题.

这对我来说听起来很合适.异常是可取的,因为它们可以从服务层内的任何位置抛到服务层的顶部,无论它在服务方法实现中嵌套有多深.这样可以保持服务代码的清洁,因为您知道调用演示者将始终获得问题通知.

不要抓住异常

但是,不要在演示者中捕获异常,我知道它的诱惑因为它使代码更短,但是您需要捕获特定的异常以避免捕获系统级异常.

规划简单的异常层次结构

如果要以这种方式使用异常,则应为自己的异常类设计异常层次结构.在最小值创建一个ServiceLayerException类,并在出现问题时在服务方法中抛出其中一个.然后,如果您需要抛出一个异常,该异常应该/可以由演示者以不同方式处理,您可以抛出ServiceLayerException的特定子类:例如,AccountAlreadyExistsException.

然后,您的演示者可以选择这样做

try {
  // call service etc.
  // handle success to view
} 
catch (AccountAlreadyExistsException) {
  // set the message and some other unique data in the view
}
catch (ServiceLayerException) {
  // set the message in the view
}
// system exceptions, and unrecoverable exceptions are allowed to bubble 
// up the call stack so a general error can be shown to the user, rather 
// than showing the form again.

在您自己的异常类中使用继承意味着您不需要在演示者中捕获多重异常 - 如果需要,您可以 - 并且您最终不会意外捕获无法处理的异常.如果您的演示者已经位于调用堆栈的顶部,请添加一个catch(Exception)块以使用不同的视图处理系统错误.

我总是试着将我的服务层视为一个单独的可分发库,并将其视为具体的异常.然后由演示者/控制器/远程服务实现决定是否需要担心特定细节或仅将问题视为一般错误.