【问题标题】:WPF. MVVM. Using events is a bad tone?WPF。 MVVM。使用事件是一种不好的语气?
【发布时间】:2011-08-28 10:13:40
【问题描述】:

在使用 MVVM 模式时,事件的使用是否被认为是不好的,所有 UI 逻辑都应该通过命令来实现?

【问题讨论】:

  • 取决于您所指的事件类型。路由事件是 WPF MVVM 的主要内容之一。
  • 我在我的 WPF 应用程序中广泛使用代码隐藏 communicating with the DWM API。例如,我使用的事件之一是Window.OnSourceInitialized,用于与 WPF 窗口的 Win32 句柄进行通信。这是绝对属于视图及其代码隐藏的 UI 逻辑,而不是其他任何地方,并且与命令完全无关。

标签: .net wpf events mvvm command


【解决方案1】:

为了补充 ColinE 的答案,可以使用事件 ,但允许代码隐藏事件的问题在于它是一个滑坡。您添加一件事,然后添加另一件事,突然之间,您在代码隐藏类中创建了实际逻辑。 (如果您与团队中其他经验较少的程序员一起工作,这一点会更加突出)。

这就是为什么我更愿意(几乎没有例外)根本不编写代码隐藏。 每个适合隐藏代码而不是真正的应用程序逻辑代码的代码也可以在行为中编写,这使得架构更加严格和易于定义。

此外,作为 WPF4 的强大补充,行为本质上是非常封装且非常可重用的,因此通常使用任何标准的行为都会更好。

【讨论】:

    【解决方案2】:

    这取决于事件的使用方式。如果您将事件用于特定于 UI 的效果,我相信您会很好。毕竟,您的视图定义了 UI 的行为方式,因此它甚至是将您的 UI 特定逻辑放入视图中的代码中的正确位置。

    但是,您的应用程序/业务逻辑应该在 ViewModel 或 Model 中。在这种情况下,如果绑定不能完成工作并且事件是必要的,那么所有事件处理程序应该做的就是将所有逻辑委托给 ViewModel。

    【讨论】:

      【解决方案3】:

      值得思考 MVVM 模式真正为您提供了什么。

      • 关注点分离(适用于所有 UI 模式)
      • 通过执行不带视图的视图模型对视图逻辑进行单元测试。
      • 开发人员-设计人员工作流程,允许使用 Blend 的设计人员处理相同的代码。

      如果在后面的代码中处理UI事件并没有禁止上述情况,那就没有问题了!

      我个人会尽可能使用命令,但不关心是否需要一些代码隐藏。

      【讨论】:

      • 完全同意。不使用代码隐藏,不使用事件等是让您思考“等一下。有更多 mvvm-y 方法来做到这一点吗?”如果没有,那就继续吧。
      • 我同意。如果它只是不涉及状态或逻辑的简单视图接线,则可以查找代码隐藏。
      猜你喜欢
      • 2010-11-25
      • 1970-01-01
      • 1970-01-01
      • 2014-05-20
      • 1970-01-01
      • 2011-04-22
      • 1970-01-01
      • 1970-01-01
      • 2019-08-04
      相关资源
      最近更新 更多