wpf MVVM 框架：性能

MVVM Framework: Performance

提问by J4N

I'm currently searching what will be the Framework that we will use for our nexts applications. Currently we have applications running with winform and we plan to switch slowly to WPF(with new application, and then refactoring the GUI). We are a team of 9 people working this solution.

我目前正在搜索我们将用于下一个应用程序的框架是什么。目前我们有使用 winform 运行的应用程序，我们计划慢慢切换到 WPF（使用新应用程序，然后重构 GUI）。我们是一个由 9 人组成的团队，正在处理此解决方案。

We have a big solution(currently, 300+ VS projects, ~1'500'000 line of code), so when choosing a framework, we are looking for something which will promote a clean code, a good infrastructure, but also a framework that will not slow(too much) the application.

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

Currently, I'm mainly interessted in Prism(which seems to be a little bit complex to fully understand) and Caliburn.Micro.

目前，我主要对Prism（完全理解它似乎有点复杂）和Caliburn.Micro.

The Caliburn.Micro seems easier to use, but I'm a little worried that all those convention oriented stuff means that a lot of things will be done using Reflection on runtime.

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

Am I correct? Or is this something done at the compilation ?

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

Also I'm not sure I should consider MVVM Light, since it lacks of documentation/targeted application sizes.

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

回答by Liero

First of all, Prism is not a MVVM framework. There is Prism.MVVM and it is a very lightweight MVVM library and it's independent of Prism.

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

Second, this <ListBox x:Name="Products" />automatically databound to viewmodel should not be a performance problem in Caliburn.Micro, because plain Binding in WPF uses refelection anyway. Not sure if Caliburn uses reflection internally as well, but even if it does, it's hardly noticable at runtime if you dont do it in iterative scenario, e.g. inside ItemsScontrol with 1000+ items. If you experience preformance issues, nothing prevents you from writing it the standard way. However, the added value of this is questionable. IMO it brings more problems than it solves

其次，这种<ListBox x:Name="Products" />自动数据绑定到视图模型在 Caliburn.Micro 中不应该是性能问题，因为 WPF 中的普通绑定无论如何都会使用重新选择。不确定 Caliburn 是否也在内部使用反射，但即使它确实如此，如果您不在迭代场景中这样做，则在运行时也几乎不会引起注意，例如在具有 1000 多个项目的 ItemsScontrol 中。如果您遇到性能问题，没有什么可以阻止您以标准方式编写它。然而，这种附加值是值得怀疑的。IMO 带来的问题多于解决的问题

If I may give you my advice, don't use any MVVM framework. All you need is INotifyPropertyChangedimplementation and DelegateCommand(ICommandimplementation). In some special cases you may need EventAggregator. Now tell me, are those three classes worth a framework? No, the aren't. Why introduce a dependency to a third party library?

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

If you are going to start such a large solution, the investment to write your own base class library is negligible. You can always take the source code of a class or two from Prism and use them in your own library.

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

The problem with those framework is that developers tend to over-engineer simple scenarios, such as using EventAggregatorwhere plain event or even direct reference is more suitable. Or take Prism as an example, they use regions and view injection where simple ItemsControlcould be used.

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

After 6 years experience with WPF I became a big proponent of ViewModel-First approach. MVVM then becomes much simpler. But most frameworks work better with View-First approach.

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

So, my vote is to not use any MVVM framework. If you have to use one, choose Prism.MVVM. And look at the source codes, they are well written.

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

回答by mvermef

I have used CM for a few years, start back when it was 1.1. I came over from PRISM. While I agree for some of the comments and points of view from other posters, you truly only option at this stage is to get the library/framework (which ever you choose to play with), wire it up and run with it a little bit in your off time from major projects. Implementing it on your "paid time" might be less than beneficial since you will undoubtedly have questions while "experimenting".

我已经使用 CM 几年了，从 1.1 开始。我是从 PRISM 过来的。虽然我同意其他海报的一些评论和观点，但在此阶段您真正唯一的选择是获取库/框架（无论您选择使用哪个），将其连接起来并稍微运行一下在重大项目的空闲时间。在您的“有偿时间”实施它可能没有什么好处，因为您在“实验”时无疑会遇到问题。

Experiment first then make your decision. Want separation of concerns? Want rapid development? Want to be able to drop a control on workspace name it and it will just work (assuming it has a built-in convention, or create your own convention for a 3rd party control), wire some viewmodel code up to a property or method that you named the control, then give Caliburn.Micro a try. Don't want to use Caliburn's conventions then don't. Just about everything for CM is modularized in to core needs with Nuget installs.

先试验再做决定。想要关注点分离？想要快速发展？希望能够在工作区上放置一个控件，命名它并且它可以正常工作（假设它有一个内置约定，或者为第 3 方控件创建您自己的约定），将一些视图模型代码连接到一个属性或方法您为控件命名，然后尝试 Caliburn.Micro。不想使用 Caliburn 的约定就不要使用。通过 Nuget 安装，CM 的几乎所有内容都模块化以满足核心需求。

There are many MVVM frameworks as well as libraries all have different niche areas some are multi-platform, some are laser targeted on 1 platform. You can only use what you try and at the end of the day if you find something you like using and it works for you and your team, then it (framework/library) is the one that should be targeted.

有许多 MVVM 框架以及库都有不同的利基领域，有些是多平台的，有些是针对 1 个平台的激光目标。你只能使用你尝试过的东西，如果你发现你喜欢使用的东西并且它对你和你的团队有用，那么它（框架/库）就是应该定位的对象。

Example of why I left PRISM

我离开 PRISM 的原因示例

On the View

在视图上

<Button x:Name="ClickMe" />

<Button x:Name="ClickMe" />

In the ViewModel

在视图模型中

public void ClickMe()
{
}

public string FirstName
{
  get{...}
  set
{
    _firstname = value;
    NotifyOfPropertyChange();
    NotifyOfPropertyChange( () => CanClickMe); )
}


public bool CanClickMe
{
    get { return !string.IsEmptyOrNull(_firstname); }
}

回答by Rico Suter

Most WPF performance problems are not caused by the MVVM framework but how you implement your WPF application (e.g. are you using virtualized lists?). I think you should select your MVVM framework depending on your function needs (are all functionalities available, e.g. a command implementation, view model base class).

大多数 WPF 性能问题不是由 MVVM 框架引起的，而是由您如何实现 WPF 应用程序引起的（例如，您是否使用了虚拟化列表？）。我认为您应该根据您的功能需求选择您的 MVVM 框架（所有功能都可用，例如命令实现、视图模型基类）。

It is more important to define conventions and rules for implementing your MVVM/WPF and select the MVVM framework based on these rules. Some conventions and rules can be found in my article about recommendations and best practices for implementing MVVM and XAML/.NET applications.

更重要的是定义实现 MVVM/WPF 的约定和规则，并根据这些规则选择 MVVM 框架。一些约定和规则可以在我关于实现 MVVM 和 XAML/.NET 应用程序的建议和最佳实践的文章中找到。

There are lots of resources about choosing the right MVVM framework, for example:

有很多关于选择正确的 MVVM 框架的资源，例如：

• What framework for MVVM should I use?
• https://social.msdn.microsoft.com/Forums/vstudio/en-US/c8accd7e-69c1-48af-bf5a-4275910c2b9e/which-mvvm-framework-to-choose

• 我应该使用什么 MVVM 框架？
• https://social.msdn.microsoft.com/Forums/vstudio/en-US/c8accd7e-69c1-48af-bf5a-4275910c2b9e/which-mvvm-framework-to-choose