wpf - MVVM 框架 : Performance

Question

我目前正在搜索我们将用于下一个应用程序的框架。目前我们有应用程序使用 winform 运行，我们计划慢慢切换到 WPF(使用新应用程序，然后重构 GUI)。我们是一个由 9 人组成的团队，致力于解决这个问题。

我们有一个很大的解决方案(目前，300+ VS 项目，~1'500'000 行代码)，所以在选择框架时，我们正在寻找能够促进干净代码、良好基础设施以及框架的东西这不会减慢(太多)应用程序。

目前，我主要对Prism感兴趣(完全理解似乎有点复杂)和Caliburn.Micro .

Caliburn.Micro 似乎更易于使用，但我有点担心所有这些面向约定的东西意味着很多事情将在运行时使用反射完成。

我对么？或者这是在编译时完成的？

另外我不确定我应该考虑 MVVM Light，因为它缺乏文档/目标应用程序大小。

Answer 1

首先，Prism 不是 MVVM 框架。 Prism.MVVM 是一个非常轻量级的 MVVM 库，它独立于 Prism。

二、本<ListBox x:Name="Products" />在 Caliburn.Micro 中自动将数据绑定(bind)到 View 模型不应该是性能问题，因为 WPF 中的普通绑定(bind)无论如何都使用反射。不确定 Caliburn 是否也在内部使用反射，但即使这样做，如果您不在迭代场景中执行它，在运行时也几乎不会注意到它，例如在 ItemsScontrol 中包含 1000 多个项目。如果您遇到性能问题，没有什么能阻止您以标准方式编写它。然而，它的附加值(value)是值得怀疑的。 IMO带来的问题多于解决的问题

如果我可以给你我的建议，请不要使用任何 MVVM 框架。您只需要INotifyPropertyChanged实现和DelegateCommand (ICommand 实现)。在某些特殊情况下，您可能需要 EventAggregator .现在告诉我，这三个类值得一个框架吗？不，不是。为什么要引入第三方库的依赖？

如果您要启动如此庞大的解决方案，编写自己的基类库的投资可以忽略不计。您始终可以从 Prism 获取一两个类的源代码，并在您自己的库中使用它们。

这些框架的问题是开发人员倾向于过度设计简单的场景，例如使用 EventAggregator普通事件甚至直接引用更合适。或者以 Prism 为例，他们使用简单的区域和 View 注入(inject) ItemsControl可用于。

经过 6 年的 WPF 经验后，我成为 ViewModel-First 方法的大力支持者。 MVVM 然后变得简单得多。但大多数框架使用 View-First 方法效果更好。

所以，我的投票是不使用任何 MVVM 框架。如果必须使用一个，请选择 Prism.MVVM。看看源代码，它们写得很好。