I ran across this good post today while searching on using objects represented as a MonoState or Singleton pattern in WPF databinding:

Monostate vs. Singleton : Adventures in WPF Databinding [The .NET Addict's Blog]

The gist of it is that objects represented as a MonoState may not work property with property update notifications.  This kind of makes sense as the UI will be bound not to the actual object, but the wrapper around the internal singleton.  Hence, property change notifications on the singleton may not make it up to the UI since they bubble up but there really isn't anywhere to go as they are not actually bound to a UI control.

So, the summary is be careful if you do this.

One of the things that I typically like to do when writing an application is to code one or more "Model" objects.  A model object is an object that represents a representation of domain objects and that provide a unified interface to those objects similar to what is provided by using the 'Facade" pattern.

I typically create the model object(s) in the constructor of the application, and then allow access to them through properties in the application object.  Since the application object is a singleton (yes, another pattern) any other object (specificailly those that are WPF framework objects) can access this singleton and also the domain objects of the application. 

The advantage of this is that it provides the ability to have a centralized place to access the objects instead of having to either spread them out all over the application, or to constantly have to serialize / deserialize them from persistent medium.

In an application that I am currently building I am doing this, and I have a user control (actually I have a few) that during initialization need to access the model object during their initialization to pre-populate their data (such as items in a listbox).  Matter of fact, this is actual code that I had that was doing just that:



This code works great at runtime, but it has issues at design time.  At design time, when editing a control, the designer actually instantiates an instance of the control to provide the designer with a visual representation and access to the properties of the control in the property editor.  However, at this time, since it is design and not run time, the App.Current object is NULL!  I guess that this makes sense, but it caused an exception to be thrown that renders an error message in the designer :-(.

The initial reaction I had to this when I figured it out was to change the code to be the following, which solves the problem quite handily:

However, this works well if you are working within your solution within VS.NET.  As this model has other issues, as described in this article.  The If statement will solve the problem within your own solution, but if the control is being used by another application at design time such as Blend, then the Application.Current object may not be your application object but Blends application object, and hence the TorrentModel property many not be found.

Second, although this code works fine within your own solution, I hate that I am now putting special code into the app to test for design time operation.  This then gets back to how can I remove this code and do this just in XAML?

Well, that will be the topic of a future post.