ReactiveUI生产准备好了吗？(Is ReactiveUI Production Ready?)

ReactiveUI生产准备好了吗？(Is ReactiveUI Production Ready?)

我一直在研究在生产代码中使用Reactive UI的可行性。 其中一些功能非常有吸引力，但我担心会依赖此库。 这些包括：

怪诞的命名和惯例。 例如，以小写开头的受保护成员和RaiseAndSetIfChanged方法取决于以私人成员开头的下划线。 我理解Paul Betts（ReactiveUI作者）有一个Ruby背景，所以我猜这就是奇怪的命名所在。 但是，这对我来说会造成一个真正的问题，因为标准命名（按照Stylecop）在我的项目中执行。 即使它没有被执行，我也会担心由此导致的命名不一致。 缺乏文件/样品。 有一些文件和一个孤独的样本。 但是，文档只是一系列（旧）博客帖子，而示例基于库的V2（现在位于V4）。

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

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

我已经广泛使用MVVM Light。 我知道保罗做了一篇博客文章，他解释说你可以在技术上使用两者，但我更关心可维护性。 我怀疑在混合编码的基础上会引起混乱。

有没有人有在生产中使用Reactive UI的实践经验？ 如果是这样，你是否能够减轻或解决我的上述担忧？

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:

Whacky naming and conventions. For example, protected members starting with lower case, and the RaiseAndSetIfChanged method 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. Lack of documentation/samples. There is some documentation 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).

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 IWantsToRegisterStuff interface 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?

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.

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?

最满意答案

让我们一块一块地审视你的担忧：

＃1。 “蹩脚的命名和惯例。”

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

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

＃2。 缺乏文件/样品

这是合法的，但这里有更多文档/样本：

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

＃3。 “我会认为一个更好的方法是定义一个非常简单的接口，然后在ReactiveUI中提供扩展方法来促进所有必需的重载”

相反，实施IRxUILogger ，它只有两种方法:) ReactiveUI将填补剩下的部分。 IRxUIFullLogger只存在于你需要的地方。

“另外，这个怪异的IWantsToRegisterStuff接口”

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

“我怀疑如果两者都混在一个代码库中，这会非常令人困惑。”

不是真的。 只要将其视为“MVVM Light with SuperPowers”即可。

Let's go through your concerns piece by piece:

#1. "Whacky naming and conventions."

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:

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

#2. Lack of documentation/samples

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

#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"

Implement IRxUILogger instead, it has a scant two methods :) ReactiveUI will fill in the rest. IRxUIFullLogger is only there if you need it.

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

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.

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

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