【问题标题】:Model View Controller - How to divide the code?Model View Controller - 如何划分代码?
【发布时间】:2014-12-20 09:29:28
【问题描述】:

我有一个更一般的问题,关于如何在 MVC 模式中划分模型、视图和控制器的代码和职责。为了更好地理解,我将使用一个示例案例。

我的问题

应用程序分为模型、视图和控制器。在模型级别的某些操作期间如何处理应显示在视图中的错误?

我想到了两种可能:

a) 模型保存错误字符串并通知控制器和视图。然后视图从模型中轮询错误字符串并保存它。然后控制器告诉视图显示错误。

b) 模型将错误返回给控制器,控制器将其传递给要显示的视图。

您认为哪种方式最适合 MVC 模式? 或者什么更接近 MVC 模式?

非常感谢您

【问题讨论】:

  • 根据我对某些框架的经验,您可以在控制器中捕获异常以执行控制器执行的操作 - 写入模型。然后你可以抛出一个适合错误的视图。

标签: design-patterns model-view-controller architecture architectural-patterns


【解决方案1】:

主要有两种方法:

首先我们应该记住Command Query Separation (CQS) principle

因此,我们预计在更改模型状态时会出现命令错误。

您的模型可以抛出某种BusinesModelException 异常或返回值option typeNone 则表示成功(没有错误),Some 包含有关错误的信息。

拥有操作结果可以更容易地在验证期间聚合错误,例如,通过方法的签名显式地通知调用者返回的错误。例如,在 C# 中,如果没有正确记录,则可能引发哪些异常并不是很明显。
如果您有大量操作,其中一些操作返回错误,则异常也不利于性能。
当没有抛出异常时,我们通常暗示应用程序没有损坏状态并且操作结果更自然地传达了这一点,而异常需要约定(无论它是否可恢复)。

另一方面,异常可以跨层传播到真正需要处理的地方。这使代码更清晰:例如,我根本不需要捕获 biz 逻辑异常,而是在 MVC 中创建一个异常过滤器,将其正确转换为适当的 htmls 状态代码和错误消息。中间层也不知道与错误相关的所有厨房。

异常也更容易适应面向方面的编程。

这两种方法可以结合使用。

我更喜欢例外。

【讨论】:

  • 感谢您的回答。所以在 MVC 中,控制器会捕获模型上的操作异常并将其传递给要显示的视图?
  • 我的回答是肯定的。控制器知道视图(客户端表示),为视图准备数据是他的责任。但是,如果我们决定在不同的用户授权级别由于安全要求而需要不同的错误表示,则这种准备可能具有相当复杂的逻辑。
  • 这篇博文和 cmets 对你来说可能很有趣,我想:blog.ploeh.dk/2014/12/23/exception-messages-are-for-programmers
  • 谢谢,看起来很有趣!
猜你喜欢
  • 2014-01-10
  • 1970-01-01
  • 2011-12-04
  • 1970-01-01
  • 2012-02-10
  • 1970-01-01
  • 2015-05-14
  • 2011-05-31
  • 2015-02-22
相关资源
最近更新 更多