ReactiveUI, View/ViewModel injection and DI in general

Question

Lately I've trying to get myself into the new age of UI development and discovered ReactiveUI. I love its declarative nature.

I wanted to make a complete switch, so I tried to understand how are things made in this new world of ReactiveUI. I choose ReactiveUI because I've seen that is maintained by a very clever guy (Paul C. Betts).

I'm very new to it and I will likely be flooding StackOverflow with questions about it because I has a huge power and I think it deserves to be learnt and mastered.

Let's get into the details:

I've always used View-First. I'm a veteran user of the Cinch Framework (http://cinch.codeplex.com/)

It uses MEF to inject the ViewModels to each View. You just have to decorate your ViewModel with [ViewModel("SampleView")] and add an Attached Property to your View (ViewModelLocator.ViewModel="SampleView"), and whenever the View is Loaded, the corresponding ViewModel is instantiated and injected as its DataContext with the life cycle you choose.

This mechanism, while it's valid, has some inconveniences. The worst of them: It uses a Locator.

As Mark Seemann suggest in his book, ServiceLocator is an anti-pattern that should be avoided.

1. So my first question is: is ReactiveUI built on top of a Locator-based infrastructure?
2. View-First or ViewModel-First? What's better in terms of good practices, decoupling, SOLID, and stuff like these that are concerns of a crazy, pro-Microsoft Clean Code lover like me? Which will make me sleep better and provide my application with all those *ibility goodness?

Answer 1

ServiceLocator is an anti-pattern that should be avoided.

I generally think a lot of the advice around IoC/DI is pretty bad in the domain of 'cross-platform mobile applications', because you have to remember that a lot of their ideas were written for web apps, not mobile or desktop apps.

For example, the vast majority of popular IoC containers concern themselves solely with resolution speed on a warm cache, while basically completely disregarding memory usage or startup time - this is 100% fine for server applications, because these things don't matter; but for a mobile app? Startup time is huge.

Splat's Service Location solves a number of issues for RxUI:

1. Service Location is fast, and has almost no overhead to set up.
2. It encapsulates several different common object lifetime models (i.e. 'create new every time', 'singleton', 'lazy'), just by writing the Func differently
3. It's Mono Linker friendly (generally)
4. Service Location allows us to register types in platform-specific code, but use them in PCL code.

The best way to use Service Locator

In fact, I do generally agree with Mark Seemann, in that constructor injection is the preferred way to go - this is the pattern I really like:

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

This uses a Service Located interface for the default interface, but only if the caller didn't give an explicit one in the constructor. Far more straightforward to test in a unit test runner than trying to construct a sham IoC container, but still falls back to a default implementation at runtime.

View-First or ViewModel-First?

Whether you can use VM-based routing (i.e. RoutedViewHost, IScreen, RoutingState, and friends) in ReactiveUI depends on the platform you're on:

• WPF, Xamarin Forms: Absolutely
• WP8, WinRT: You can make it work, you lose some transitions and niceties
• Android, iOS Native: Very difficult to make work