我目前正在从 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 无法预料的规则。

目前,如果事情没有按计划进行,我会让服务层抛出异常。这是一个足够的策略吗?这段代码对你们来说有味道吗?如果我编写了这样的服务层,您是否会因为必须编写以这种方式使用它的 Presenter 而感到恼火?返回码似乎太老套了,布尔值的信息量不够。


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


Cheekysoft,我喜欢 ServiceLayerException 的概念。我已经有一个全局异常模块来处理我没有预料到的异常。您是否觉得制作所有这些自定义例外很乏味?我认为捕获 Exception 基类有点难闻,但不确定从那里取得的进展如何。

tgmdbm,我喜欢那里巧妙地使用 lambda 表达式!


感谢 Cheekysoft 的跟进。因此,我猜测如果您不介意在未处理异常的情况下向用户显示单独的页面(我主要是网络开发人员),那么这将是一种策略。

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

当 Presenter 处理了 ServiceLayerException 时,CreateUserView 的样子如下:

Create a user

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

无论如何,我认为我们现在超出了我最初问题的范围。我会研究您发布的内容,如果我需要更多详细信息,我会发布一个新问题。

有帮助吗?

解决方案

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

不要捕获异常

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

规划一个简单的异常层次结构

如果要以这种方式使用异常,则应该为自己的异常类设计异常层次结构。至少创建一个 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) 块以使用不同的视图处理系统错误。

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

其他提示

正如 Cheekysoft 建议的那样,我倾向于将所有主要异常移至 ExceptionHandler 中,并让这些异常冒泡。ExceptionHandler 将为异常类型呈现适当的视图。

然而,任何验证异常都应该在视图中处理,但通常这种逻辑对于应用程序的许多部分都是通用的。所以我喜欢有一个这样的帮手

public static class Try {
    public static List<string> This( Action action ) {
      var errors = new List<string>();
      try {
        action();
      }
      catch ( SpecificException e ) {
        errors.Add( "Something went 'orribly wrong" );
      }
      catch ( ... )
      // ...
     return errors;
    }
}

然后,当致电您的服务时,只需执行以下操作

var errors = Try.This( () => {
  // call your service here
  tasks.CreateMember( ... );
} );

然后错误是空的,你就可以开始了。

您可以更进一步,并使用处理异常的客户异常处理程序来扩展它 罕见 例外情况。

回答后续问题:

至于创建异常变得乏味,你已经习惯了。使用良好的代码生成器或模板可以在大约 5 或 10 秒内以最少的手动编辑创建异常类。

然而,在许多现实世界的应用程序中,错误处理可能占工作量的 70%,因此这实际上只是游戏的一部分。

正如 tgmdbm 所建议的,在 MVC/MVP 应用程序中,我让所有无法处理的异常冒泡到顶部,并被委托给 ExceptionHandler 的调度程序捕获。我对其进行了设置,以便它使用 ExceptionResolver 在配置文件中查找以选择适当的视图来向用户显示。Java 的 Spring MVC 库在这方面做得很好。这是 Spring MVC 异常解析器的配置文件的片段 - 它适用于 Java/Spring,但您会明白的。

这需要您的演示者/控制器进行大量的异常处理。

<bean id="exceptionResolver"
      class="org.springframework.web.servlet.handler.SimpleMappingExceptionResolver">

  <property name="exceptionMappings">
    <props>
      <prop key="UserNotFoundException">
        rescues/UserNotFound
      </prop>
      <prop key="HibernateJdbcException">
        rescues/databaseProblem
      </prop>
      <prop key="java.net.ConnectException">
        rescues/networkTimeout
      </prop>
      <prop key="ValidationException">
        rescues/validationError
      </prop>
      <prop key="EnvironmentNotConfiguredException">
        rescues/environmentNotConfigured
      </prop>
      <prop key="MessageRejectedPleaseRetryException">
        rescues/messageRejected
      </prop>
    </props>
  </property>
  <property name="defaultErrorView" value="rescues/general" />
</bean>
许可以下: CC-BY-SA归因
不隶属于 StackOverflow
scroll top