Awkward Coder

Having just published Simple.Wpf.Terminal as a nuget package I wanted the ability to skin the user control - the more flexibility in the way it looks the more likely it will be used by other devs :) Before getting into the detail, lets look at the solution working in the test harness for my WPF F# REPL Engine , shown below are four different themes applied dynamically at run-time - no recompilation required to change the theme: Previously in larger WPF apps I've relied upon third-party control vendors like Telerik to provide theming support. Typically they provide good solutions to the problem with multiple themes supported as standard, and when you're already using their third party controls the use of their themes makes sense. But when you're developing a small UI component you don't want to add (& support) such a large footprint just to add themes to your niche control. A theme is a collection of Styles grouped into a ResourceDictionary in WPF. A ...

This is another anti-pattern I've seen a lot recently, the dynamic use of the IoC container inside a view model to resolve child view models & services - service locator pattern: The service locator pattern has been around for a while - Fowler was writing about this back in 2004! It's not a pattern that is specific to MVVM, it's a pattern associated with using DI & IoC, if you're doing MVVM you should be using DI & IoC . A lot has also be written about this being an anti-pattern and I agree completely with Mark Seaman on the topic. For me why this is an anti-pattern for MVVM is for the following reasons: Breaks SOLID principles - the view model now has multiple responsibilities and not all dependencies are being explicitly injected. The view model is now responsible for the lifetime of anything it has resolved (this includes scope as well) , Encourages view models to become god-like objects - they become bloated - all the implementation in...