wpf ReactiveUI 生产准备好了吗？

Is ReactiveUI Production Ready?

提问by Kent Boogaart

I've been looking into the feasability of using Reactive UI in production code. Some of the features are really appealing, but I have concerns about taking a dependency on this library. These include:

我一直在研究在生产代码中使用 Reactive UI 的可行性。有些功能确实很吸引人，但我担心依赖于这个库。这些包括：

1. Whacky naming and conventions. For example, protected members starting with lower case, and the RaiseAndSetIfChangedmethod depends on your private member beginning with an underscore. I understand Paul Betts (ReactiveUI author) has a Ruby background, so I guess that's where the odd naming stems from. However, this will cause a real issue for me, since standard naming (as per Stylecop) is enforced throughout my project. Even if it wasn't enforced, I'd be concerned by the resultant inconsistency in naming that this will cause.
2. Lack of documentation/samples. There is somedocumentation and a lonely sample. However, the documentation is just a series of (old) blog posts and the sample is based on V2 of the library (it's now on V4).

3. Odd design, in parts. For example, logging is abstracted so as not to take a dependency on a specific logging framework. Fair enough. However, since I use log4net (and not NLog) I will need my own adapter. I think that will require me to implement IRxUIFullLogger, which has a metric crapload of methods in it (well over 50). I would have thought a far better approach would be to define a very simple interface and then provide extension methods within ReactiveUI to facilitate all the requisite overloads. In addition, there's this weird IWantsToRegisterStuffinterface that the NLog assembly depends on, that I won't be able to depend on (because it's an internal interface). I'm hoping I don't need that...

   Anyway, my concern here is the overall design of the library. Has anyone been bitten by this?

4. I'm already using MVVM Light extensively. I know Paul did a blog post where he explains you can technically use both, but my concern is more around maintainability. I suspect it would be horribly confusing having both intermingled in one's code base.

1. 古怪的命名和约定。例如，受保护成员以小写开头，RaiseAndSetIfChanged方法取决于您的私有成员以下划线开头。我知道 Paul Betts（ReactiveUI 作者）有 Ruby 背景，所以我猜这就是奇怪命名的来源。然而，这会给我带来一个真正的问题，因为标准命名（按照 Stylecop）在我的项目中被强制执行。即使没有强制执行，我也会担心这会导致命名不一致。
2. 缺乏文档/样本。有一些文档和一个孤独的样本。但是，文档只是一系列（旧）博客文章，示例基于库的 V2（现在是 V4）。

3. 奇怪的设计，部分。例如，日志是抽象的，以便不依赖于特定的日志框架。很公平。但是，由于我使用 log4net（而不是 NLog），因此我需要自己的适配器。我认为这将需要我实施IRxUIFullLogger，其中包含大量方法（远远超过 50）。我原以为更好的方法是定义一个非常简单的接口，然后在 ReactiveUI 中提供扩展方法以促进所有必需的重载。此外，还有IWantsToRegisterStuffNLog 程序集依赖的这个奇怪的接口，我将无法依赖它（因为它是一个内部接口）。我希望我不需要那个...

   无论如何，我在这里关心的是图书馆的整体设计。有人被这个咬过吗？

4. 我已经在广泛使用 MVVM Light。我知道 Paul 写了一篇博文，他解释说你可以在技术上同时使用这两种方法，但我更关心的是可维护性。我怀疑将两者混合在一个人的代码库中会非常混乱。

Does anyone have hands-on experience with using Reactive UI in production? If so, are you able to allay or address any of my above concerns?

有没有人有在生产中使用 Reactive UI 的实践经验？如果是这样，您能否减轻或解决我的上述任何问题？

采纳答案by Ana Betts

Let's go through your concerns piece by piece:

让我们逐一解决您的疑虑：

#1. "Whacky naming and conventions."

#1. “古怪的命名和约定。”

Now that ReactiveUI 4.1+ has CallerMemberName, you don't have to use the conventions at all (and even then, you can override them via RxApp.GetFieldNameForPropertyFunc). Just write a property as:

现在 ReactiveUI 4.1+ 有 CallerMemberName，你根本不需要使用这些约定（即使那样，你也可以通过 覆盖它们RxApp.GetFieldNameForPropertyFunc）。只需将属性写为：

int iCanNameThisWhateverIWant;
public int SomeProperty {
    get { return iCanNameThisWhateverIWant; }
    set { this.RaiseAndSetIfChanged(ref iCanNameThisWhateverIWant, value); }
}

#2. Lack of documentation/samples

#2. 缺乏文件/样本

This is legit, but here's some more docs / samples:

这是合法的，但这里有更多文档/示例：

• http://docs.reactiveui.net/(this is the official ReactiveUI documentation, a work in progress but definitely where you want to start)
• https://github.com/reactiveui/ReactiveUI.Samples
• https://github.com/reactiveui/RxUI_QCon
• https://github.com/play/play-windows

• http://docs.reactiveui.net/（这是 ReactiveUI 的官方文档，正在进行中，但绝对是您想要开始的地方）
• https://github.com/reactiveui/ReactiveUI.Samples
• https://github.com/reactiveui/RxUI_QCon
• https://github.com/play/play-windows

#3. "I would have thought a far better approach would be to define a very simple interface and then provide extension methods within ReactiveUI to facilitate all the requisite overloads"

#3. “我认为更好的方法是定义一个非常简单的界面，然后在 ReactiveUI 中提供扩展方法以促进所有必要的重载”

Implement IRxUILoggerinstead, it has a scant two methods :) ReactiveUI will fill in the rest. IRxUIFullLoggeris only there if you need it.

实现IRxUILogger，它只有很少的两种方法 :) ReactiveUI 将填补其余部分。IRxUIFullLogger只有在您需要时才会出现。

"In addition, there's this weird IWantsToRegisterStuff interface "

“此外，还有这个奇怪的 IWantsToRegisterStuff 接口”

You don't need to know about this :) This is only for dealing with ReactiveUI initializing itself so that you don't have to have boilerplate code.

你不需要知道这个 :) 这只是为了处理 ReactiveUI 初始化本身，这样你就不必有样板代码。

4. "I suspect it would be horribly confusing having both intermingled in one's code base."

4. “我怀疑将两者混合在一个人的代码库中会非常混乱。”

Not really. Just think of it as "MVVM Light with SuperPowers".

并不真地。只需将其视为“具有超能力的 MVVM Light”。

回答by Cameron MacFarland

I am answering as someone who has used ReactiveUI in a few production systems, has had issues with the way RxUI does stuff, and has submitted patches to try and fix issues I've had.

我作为一个在一些生产系统中使用过 ReactiveUI 的人来回答，在 RxUI 做事的方式上遇到了问题，并且已经提交了补丁来尝试解决我遇到的问题。

Disclaimer:I don't use all the features of RxUI. The reason being I don't agree with the way those features have been implemented. I'll detail my changes as I go.

免责声明：我没有使用 RxUI 的所有功能。原因是我不同意这些功能的实现方式。我会在进行时详细说明我的更改。

1. Naming. I thought this was odd too. This ended up being one of the features I don't really use. I use PropertyChanged.Fody to weave in the change notification using AOP. As a result my properties look like auto properties.

2. Doco. Yes there could be more. Especially with the newer parts like routing. This possibly is a reason why I don't use all of RxUI.

3. Logging. I've had issues with this in the past. See pull request 69. At the end of the day I see RxUI as a very opinionated framework. If you don't agree with that opinion you can suggest changes, but that's all. Opinionated does not make it bad.

4. I use RxUI with Caliburn Micro. CM handles View-ViewModel location and binding, Screen and Conductors. I don't use CM's convention binding. RxUI handles Commands, and ViewModel INPC code, and allows me to react to property changes using Reactive instead of the traditional approaches. By keeping these things separate I find it much easier to mix the two together.

1. 命名。我也觉得这很奇怪。这最终成为我并没有真正使用的功能之一。我使用 PropertyChanged.Fody 使用 AOP 编织更改通知。因此，我的属性看起来像自动属性。

2. 多科。是的，可能还有更多。特别是对于路由等较新的部分。这可能是我不使用所有 RxUI 的原因。

3. 记录。我过去遇到过这个问题。请参阅拉取请求 69。归根结底，我认为 RxUI 是一个非常固执的框架。如果您不同意该意见，您可以提出更改建议，仅此而已。自以为是不会让它变坏。

4. 我将 RxUI 与 Caliburn Micro 一起使用。CM 处理 View-ViewModel 位置和绑定、屏幕和导体。我不使用 CM 的约定绑定。RxUI 处理命令和 ViewModel INPC 代码，并允许我使用 Reactive 而不是传统方法对属性更改做出反应。通过将这些东西分开，我发现将两者混合在一起会容易得多。

Does any of these issues have anything to do with being production ready? Nope. ReactiveUI is stable, has a decently sized user base, problems get solved quickly in the google groupand Paul is receptive to discussion.

这些问题中的任何一个是否与生产就绪有关？不。ReactiveUI 稳定，拥有相当规模的用户群，问题在google 组中很快得到解决，Paul 乐于讨论。

回答by AlSki

I use it in production and so far RxUI has been perfectly stable. The application has had problems with stability, some to do with EMS, others with an UnhandledException handler that was causing more problems than it was solving, but I've not had any problems with the ReactiveUI part of the application. However, I have had issues regarding the ObservableForProperty not firing at all, which I may have used incorrectly and did work consistently (incorrectly) in my test code as well as in the UI at run time.

我在生产中使用它，到目前为止 RxUI 一直非常稳定。该应用程序存在稳定性问题，有些与 EMS 相关，有些与 UnhandledException 处理程序有关，该处理程序导致的问题多于解决的问题，但我对应用程序的 ReactiveUI 部分没有任何问题。但是，我遇到了关于 ObservableForProperty 根本没有触发的问题，我可能没有正确使用它并且在我的测试代码以及​​运行时的 UI 中一直（错误地）工作。

-1. Paul explains that the _Upper is due to using reflection to get at the private field in your class. You can either use a block such as below to deal with the StyleCop and Resharper messages, which is easy to generate (from the Resharper SmartTag)

-1. Paul 解释说 _Upper 是由于使用反射来获取您班级中的私有字段。您可以使用如下块来处理 StyleCop 和 Resharper 消息，这很容易生成（来自 Resharper SmartTag）

    /// <summary>The xxx view model.</summary>
    public class XXXViewModel : ReactiveObject
    {
    #pragma warning disable 0649
    // ReSharper disable InconsistentNaming

    [SuppressMessage("StyleCop.CSharp.NamingRules", 
      "SA1306:FieldNamesMustBeginWithLowerCaseLetter",
      Justification = "Reviewed. ReactiveUI field.")]
    private readonly bool _IsRunning;

    [SuppressMessage("StyleCop.CSharp.NamingRules", 
      "SA1306:FieldNamesMustBeginWithLowerCaseLetter",
      Justification = "Reviewed. ReactiveUI field.")]
    private string _Name;
    ....

or change your properties from the full

或从完整更改您的属性

    /// <summary>Gets or sets a value indicating whether is selected.</summary>
    public bool IsSelected
    {
        get { return _IsSelected; }
        set { this.RaiseAndSetIfChanged(x => x.IsSelected, value); }
    }

to its component parts such as

到其组成部分，例如

    /// <summary>Gets or sets a value indicating whether is selected.</summary>
    public bool IsSelected
    {
        get { return _isSelected; }
        set 
        { 
            if (_isSelected != value)
            {
                this.RaisePropertyChanging(x => x.IsSelected); 
                _isSelected = value;
                this.RaisPropertyChanged(x=>x.IsSelected);
            }
        }
    }

This pattern is also useful where you don't actually supply a "simple" property accessor, but may require a more derived variant where setting one value affects multiple others.

当您实际上不提供“简单”属性访问器时，此模式也很有用，但可能需要更派生的变体，其中设置一个值会影响多个其他值。

-2. Yes the documentation isn't ideal but I found that after Rx, picking up the RxUI samples was quite easy. I also note that the jumps from 2->4 seem to have all come with the changes to support Windows 8/Windows 8 Phone, and having picked up ReactiveUI for a Windows Store App then the DotNet 4.5 support is excellent. i.e. use of [CallerName] now means that you simply this.RaiseAndSetIFChanged(value) no need for the expression.

-2. 是的，文档并不理想，但我发现在 Rx 之后，获取 RxUI 示例非常容易。我还注意到，从 2->4 的跳跃似乎都伴随着支持 Windows 8/Windows 8 Phone 的变化，并且为 Windows Store 应用程序选择了 ReactiveUI 然后 DotNet 4.5 支持非常好。即使用 [CallerName] 现在意味着您只需 this.RaiseAndSetIFChanged(value) 不需要表达式。

-3. I haven't any feedback on the logging side as I've not elected to use it.

-3. 我在日志方面没有任何反馈，因为我没有选择使用它。

-4. I've not mixed and matched with others frameworks either.

-4. 我也没有与其他框架混合和匹配。

There's also a list of other contributors to ReactiveUI 4.2 at http://blog.paulbetts.org/index.php/2012/12/16/reactiveui-4-2-is-released/, including Phil Haack.

在http://blog.paulbetts.org/index.php/2012/12/16/reactiveui-4-2-is-released/上还有一个 ReactiveUI 4.2 的其他贡献者列表，包括 Phil Haack。