In MVVM there are lots of elaborate ways to make sure our XAML’s DataContext is correctly instantiated, and if you are using IoC then you should be letting the IoC container instantiate your viewmodel, which doesn’t fit naturally into the XAML view paradigm.
I see a lot of developers writing code in their ViewModels that include a lot of data initialization logic that is performed eagerly, before the data is required. Most developers believe that lazy initialization is a tricky thing to achieve in MVVM, because it is difficult to know when exactly a XAML data binding will need the data in question.
Here’s another quickie
Question : Does your DataContext (or ViewModel if you’re doing MVVM) have to implement INotifyPropertyChanged in order to participate in XAML data binding and change synchronization (and all other goodies that follow)
Answer: Absolutely NOT !
Just a quickie
You have MVVM and you have properties that notify via INotifyPropertyChanged.
Question : Do I have to use Dispatcher.BeginInvoke in order to change my bound properties in my ViewModel (i,e. when changing property values on background threads)
My current contract is within FX trading, supporting a front-office team with high-performance, low latency applications.
We are currently doing a refactoring exercise around our currency pair data feeds, and we are looking to code better data consumption logic through implementations of IObsrevable and IObserver, courtesy of the Reactive Extensions library.
Ive decided to put a LOT more effort into my blogging, and will be creating regular posts on this blog that discuss advanced features and solutions in the .NET C#, WPF and XAML.
I hope you enjoy the posts Im going to write. My existing blog posts were imported from another blog provider, so may not be perfectly matched to this layout. I will be going through each one and ‘making good’.
Feel free to contact me on my social networking profiles, or directly at me email address.
Your debugging your code, and you have the need to change the value of a variable automatically without changing any code. Perhaps the URL of a production webservice is valid and cannot be changed in code, but you want to switch it to a development URL There are several ways of doing this, but only when the code execution has stopped at a breakpoint, and you need to change it every time manually.
As .NET developers we have all implemented dictionaries. Often, its a small dictionary with strings or Guids as the key – which is simple and robust.
However, sometimes we need to do something a little more ‘serious’ and implement a dictionary that has a complex key consisting of a combination of values. In this case, it is extremely important that the type we use for the key has the following characteristics:
In a Model-View-ViewModel (MVVM) project, the ViewModel can easily become a large and unwieldy piece of code. You can break this down by creating a hierarchy of ViewModels that exist in a parent-child relationship, or you can extend the functionality of an existing ViewModel via the use of ValueConverters.
I’m currently working on a large legacy WPF project where my ViewModels often have a large number of properties, and those properties have some complex inter-relationships that need to be reflected in the behaviour of the app, via the ViewModels and XAML bindings.