Awkward Coder

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

I've seen rather a lot of this anti-pattern recently, to be explicit about what I mean, lets define this in terms of a WPF user control. Imagine the code behind file is nothing more than the auto generated code, but the XAML file contains the usual controls and bindings: The user control is used in one or more data templates as follows: The reason this is an anti-pattern is because it has introduced files into the solution which aren't required: The two highlighted files are the user control files - XAML and code behind, the resources.xaml file contains the hosting data templates. The reason why these aren't required is because the code behind for the user control is doing nothing, and therefore can be removed and the XAML can be moved into the hosting data template - now the view (MVVM) is no more than a data template:  And you can now see the user control files have been removed from the solution:

I believe explicitly using the data context in the code behind of the view (custom, user control etc) in any MVVM application is an anti-pattern. The view has no need to explicitly access the data context it is there purely for binding concerns. The following screen shot illustrates what I mean: This is an anti-pattern because the view knows about the view model - as you can see the data context is being cast to the DataContextViewModel. The view (user control) is explicitly coupled to the view model and has reduced the cohesiveness of the view - it can now only be bound to instance of DataContextViewModel. Now you could argue if it was interface this would make is more useful but this doesn't reduce the tight coupling it just gives the illusion. I guess the reason why this is common is because it makes the XAML appear very clean and simple, but this is also not ideal because it's not obvious what's being bound between the view model and the view: How should this h

I've blogged about implementing a busy indicator before, this post is an extension of this pattern to implement a message box - this is instead of using the namespace provide by the .Net framework. The UI is shown below, and when the button is clicked in the middle content it will display the message as an overlay - as you can see I've coloured it green to get your attention: As with the previous post , the XAML for the View hasn't changed it's still very simple: What's changed is the style applied to the ViewHost class, as you can see there's now a MessageOverlay as well as a BusyOverlay. You'll notice the z-order of the MessageOverlay is one less the BusyOverlay, this is to make sure the busy indicator is always displayed at the highest order and hence would be an overlay on top of the message overlay: The message overlay is trigger by the binding MessageMonitor, this is an implementation of the following interface, the one I'm using i

A common pattern you see when developing web services is the use of the Unit of Work applied to the HTTP request - anything that happens during the processing of the request is viewed as being part of the transaction and therefore when the request is completed any memory allocated during the processing of the request can be garbage collected.  Whether the request is successfully or not is irrelevant in this context the important concept is the freeing of the allocated memory- controller, services, view engines etc. This pattern takes the form of using a nested (child) lifetime scope inside the IoC container used to host the web service - each request is processed inside a unique lifetime scope and when complete this scope is disposed.   Can I apply this pattern to view models in a WPF (XAML) application? To clarify what I mean, I'm not referring to every possible view model in an application, I'm referring to the main view model for a screen within an application where