c# - 一般的 ReactiveUI、View/ViewModel 注入(inject)和 DI

Question

最近我试图让自己进入 UI 开发的新时代并发现了 ReactiveUI。我喜欢它的声明性。

我想做一个彻底的转变，所以我试图了解在这个 ReactiveUI 的新世界里，事情是如何发生的。我选择 ReactiveUI 是因为我看到它是由一个非常聪明的人(Paul C. Betts)维护的。

我对它还很陌生，我很可能会向 StackOverflow 提出关于它的问题，因为我有强大的力量，我认为它值得学习和掌握。

让我们进入细节:

我一直使用 View-First。我是 Cinch 框架的资深用户 ( http://cinch.codeplex.com/ )

它使用 MEF 将 ViewModel 注入(inject)每个 View 。您只需要用 [ViewModel("SampleView")] 装饰您的 ViewModel 并向您的 View 添加一个附加属性 (ViewModelLocator.ViewModel="SampleView")，每当加载 View 时，相应的 ViewModel 就会被实例化并作为其注入(inject)具有您选择的生命周期的 DataContext。

这种机制虽然有效，但也有一些不便之处。其中最糟糕的是:它使用定位器。

正如 Mark Seemann 在他的书中所建议的那样，ServiceLocator 是一种应该避免的反模式。

1. 所以我的第一个问题是:ReactiveUI 是建立在基于定位器的基础设施？
2. View-First 还是 ViewModel-First？就良好实践、解耦、SOLID 以及像我这样疯狂的亲 Microsoft Clean Code 爱好者所关注的类似问题而言，有什么更好的？哪个能让我睡得更好，并为我的申请提供所有这些*能力优势？

Answer 1

ServiceLocator is an anti-pattern that should be avoided.

我通常认为很多关于 IoC/DI 的建议在“跨平台移动应用程序”领域是非常糟糕的，因为你必须记住他们的很多想法是为网络应用程序而不是移动或桌面应用程序。

例如，绝大多数流行的 IoC 容器只关心热缓存上的解析速度，而基本上完全不考虑内存使用或启动时间——这对服务器应用程序来说是 100% 的，因为这些都不重要；但对于移动应用程序？启动时间很长。

Splat 的服务位置解决了 RxUI 的许多问题:

1. 服务位置快速，几乎没有设置开销。
2. 它封装了几种不同的常见对象生命周期模型(即“每次都创建新的”、“单例”、“惰性”)，只需以不同的方式编写 Func
3. 它是 Mono Linker 友好的(通常)
4. 服务位置允许我们在特定于平台的代码中注册类型，但在 PCL 代码中使用它们。

使用服务定位器的最佳方式

事实上，我大体上同意 Mark Seemann 的观点，构造函数注入(inject)是首选方式 - 这是我真正喜欢的模式:

    public SuspensionHost(ISuspensionDriver driver = null)
    {
        driver = driver ?? Locator.Current.GetService<ISuspensionDriver>();
    }

这使用服务定位接口(interface)作为默认接口(interface)，但前提是调用者没有在构造函数中给出显式接口(interface)。在单元测试运行器中进行测试比尝试构建虚假 IoC 容器要简单得多，但在运行时仍会回退到默认实现。

View-First 还是 ViewModel-First？

是否可以在 ReactiveUI 中使用基于 VM 的路由(即 RoutedViewHost、IScreen、RoutingState 等)取决于您所在的平台:

• WPF、Xamarin Forms:绝对
• WP8、WinRT:你可以让它工作，但你失去了一些过渡和细节
• Android、iOS Native:很难制作