Pattern:	Model View ViewModel (MVVM) - I'm not going to delve into the pattern itself, just the implications of some decisions faced during its application in a WPF or SilverLight application. For a better understanding of the MVVM pattern, see this MSDN article by Josh Smith, or this great MSDN article about using MEF along with MVVM, by Sandrino Di Mattia
Pattern Applications:	Primarily used in the .NET world for SilverLight, WPF, WP7 applications
At Issue:	Deciding at which layer to implement the INotifyPropertyChanged interface
	At left, a depiction of the MVVM pattern: In a typical WPF or SilverLight implementation the View portion is generally XAML, the ViewModel is C#, and the Model is C#. The View owns the ViewModel instance, and the ViewModel owns the Model instance. In some cases the Model might be re-instantiated multiple times during the life of the View - an example would be when loading, binding, and rendering a new data record from the middle tier at the user's request. In other cases the Model might be loaded once with the View and remain inert after that - an example might be a simple toolbar and the meta data that drives its commands and icons. Using XAML, the View can bind to the ViewModel and the Model (typically through view Properties), depending on the UI requirements.

The Question

A friend of mine wrote recently and asked the following question regarding an implementation of the MVVM pattern: "Is it generally desirable to implement INotifyPropertyChanged on Model classes, ViewModel classes, or both?"

The answer is, ironically or frustratingly... both are good.  The appropriate approach for your application depends on the way the Model is managed by the ViewModel. While the "Context" in this table does not address the full complexity of an application's requirements, the table entries attempt to depict typical scenarios and provide guidance when you're making implementation decisions.

How can you say "both"?

The appropriate application of this INotifyPropertyChanged interface is deterministic, and has to be evaluated in terms of the specific requirements of your application and UI. I hope this helps to provide some useful guidance in your adoption of the MVVM pattern!

The Visual Studio 2010 debugger is an awesome tool, no doubt about it. It's likely the most powerful and capable debugger ever developed for Windows or any other platform. And yet, there are times when you wish it 'knew' or exposed more detail. When you're debugging a runtime instance of your application or inspecting a mini-dump to gain insight into the state of your application, often the most useful details are the values of the variables that characterize the state of your app at that particular moment. Or if you unwind a stack trace and wish to see the state of objects prior to the call that failed, you may be disappointed by the lack of simple exposure to object state displayed in the hover-tooltips by default. 

When you're inspecting the state of an application while debugging and drilling down on your own type instances, or inspecting 3rd party assembly/DLL exposed types, the experience is likely a bit less than intuitive or optimal.

Imagine this situation, you've definately encountered it but probably never realized you had any power over the situation... You're stopped on a breakpoint in the debugger and using the mouse to hover over variables in the debugger - you're depending on the Visual Studio hover-tooltips to inspect various instance or static variable values in order to build a mental image of the state of your application.

Often times you wait for the popup window, then you start clicking on the '+' signs to dig deeper, but then your mouse cursor drifts off the tolerance gap of Visual Studio and the inspection pane disappears! Or you get lucky and after clicking enough you get to inspect the value of properties within an array of object instances, or subordinate to the particular object you happen to be inspecting.  But you have to click a whole-bunch-of-more-times to inspect the other instances of your type in a collection/array...

With simple native types VS quickly displays useful runtime value information. If you hover the mouse over an int or a double you will be quickly presented with the instance value. As well, with complex types that Visual Studio is already aware of you will see similarly useful inspection details exposed.

But with our own types or 3rd party types, often times all we see is the Type name. You can see by the declaration of the employees array below that each employee has distinct details that would be valuable to discern at runtime when debugging. But observe the Value column in the QuickWatch snapshot just below the employees array declaration - it simply displays the facts:

1. there's 11 items in the collection
2. the value of each is {DebuggerDisplayAttr.Employee}

Not very useful! To discover more you will have to start aiming and clicking on little plus-signs and stuff...

Again, to actually discover the values and build our mental state we have to drill down into each entry by expanding the '+' to expose deeper details. Frequently multiple levels of inspection are required to find the information we need to elucidate our mental image and derive practical benefit from our debugging exercise...

Just add a ToString() implementation...

There's a couple of options available to programmers to resolve this 'problem':

You can override the Employee object's ToString() method to expose a hard-coded, specific view of the internal state of your object instance... "Let's just add a ToString() implementation" you say - we all know that's how to expose details that the debugger recognizes. Let's see what happens...

The debugger now leverages the ToString() conversion to display the runtime instance values in our array:

This seems like a much better situation. Now when we expand our array in the debugger we see useful instance information. But it is not ideal. Let me explain: you may have a need to use ToString() for UI purposes that differentiate it from the debugging experience. Or you may have no need to declare ToString() at all on your objects, as you don't intend to render them to the UI via string casts...

There's a better way

Wouldn't it be much more useful if the debugger provided the distinct details regarding each instance in the employees list, but did so in such a way that we could implement ToString() for an object for UI display purposes, or completely disregard the need to even implement a ToString() method... And what if we could do it declaratively? As you'll see in a later post we can describe our inspection format declaratively... but in this post I will strive only to differentiate ToString() from the debugging inspection experience.

Why not just leverage the ToString() override?

For one thing, it will affect every situation where an object's instance is converted (i.e., casted) to a string - this may not be what you want. It may even conflict with your requirements! For example, you may actually need a richer (or poorer) implementation of the ToString() override to fill in a list box or write to the active window of your application. Or if that's not the case, you'll find that doing this extra, hard-coded work is overkill - maybe all you want is debugger exposure and clarity!

If clarity is your goal there's a better, more dynamic solution.

The DebuggerDisplay Attribute

By leveraging the DebuggerDisplayAttribute you can specify the display format for your object instance to the debugger. And what's more, while you can do this in the code with a simple attribute declaration, there's a way to deliver this type-exposure information to Visual Studio in a way that it recognizes and utilizes for non-native types on the fly. You don't have to modify your code, and if you want to modify what's exposed you can do so outside the context of your application (i.e., no rebuild of your app, no re-deploy, no approvals...). 

And that's not all! In my next post I will tell you how you can use this facility to expose details of 3rd party type instances that you wish to inspect in the debugger, that may not already implement a useful ToString() method, let alone a DebuggerDisplayAttribute!

First, let's see how to accomplish this in our code. It's straight forward:

namespace DebuggerDisplayAttr
{
    [DebuggerDisplay("Name = {Name}, Phone Number = {PhoneNumber}, Manager = {EmployeeManager}")]
    public class Employee
    {
        /// <summary>
        /// Properties
        /// </summary>
        public string Name { get { return new StringBuilder(FirstName).AppendFormat(" {0}", LastName).ToString(); } }
        public string FirstName { get; set; }
        public string LastName { get; set; }
        public string PhoneNumber { get; set; }
        public int ManagerId { get; set; }

        public string EmployeeManager { get { return LookupMgr(ManagerId); } }

        /// <summary>
        /// Accessor that accepts an ID and performs a lookup via the Manager class
        /// </summary>
        private string LookupMgr(int id)
        {
            return Manager.Find(id) ?? string.Empty;
        }

        public override string ToString()
        {
            return string.Format("Name: {0}, Phone Number: {1}", Name, PhoneNumber).ToString();
        }
    }
}

The key detail above is the DebuggerDisplay attribute declaration. It specifies the instance display format in metadata that the debugger recognizes at debug-time. You can leverage properties, fields, methods... anything declared in your class - note: the debugger doesn't differentiate between access modifiers - private, protected, and public fields, properties and methods are all fair game for use in this exercise.

For example, the attribute declaration leverages the EmployeeManager property, which is resolved via a call to the Manager object's Find() method... details not shown here but obviously a complex method and one who's output enrichens our debugging experience. And you might also notice that I've also left in place the ToString() method on the object.

But let's look at the inspection output in the debugger now...

Hmmmm, perhaps my demonstration is underwhelming. But if you look at the code and what's going on, you'll see the advantages of this approach. The Visual Studio debugger gives precendence to the DebuggerDisplayAttribute declaration when inspecting instance values. Conversly, at runtime, when converting your object to a string for display on a form or casting it to display its value in a window, there's no knowledge of the DebuggerDisplayAttribute declaration; Precedence falls to the ToString() declaration.

Some details to observe...

1. The [DebuggerDisplay(...)] attribute is in the System.Diagnostics namespace, so you'll need to declare the following in your entity/DTO class:
   
   using System.Diagnostics;
   
   

2. You can leverage composite properties in the attribute declaration... see the {Name} property for example.

3. You can utilize lookup methods on subordinate properties to resolve string values... the {EmployeeManager} property is an example of this technique.

4. In case you are not aware of this detail regarding attributes, [DebuggerDisplay(...)] is equivalent to [DebuggerDisplayAttribute(...)] as far as the csharp compiler is concerned... it resolves the declaration either way as long as the namespace is referenced and declared in a 'using' statement.

But what's the catch?

There's always a catch, right?  Think about the performance implications of the work that's performed by VS as a result of leveraging this technique... the debugger has to re-evaluate the attribute expression every single time it encounters an instance of your object. Depending on how you construct the display string, this could cost you! If you have 10,000 items of your type in a collection or array you're going to experience latency as the debugger resolves (evaluates) the display criteria for your type when you access the hover-tooltips and expand your collection, when you add your collection to a Watch Window and expand it, or when you access your collection instance in Quick Watch and expand it. That's why they decided to call ToString() in the first place! It's a single method that's already included on every object by definition. It's compiled, optimized, and executed quickly on every type instance.

Here's a link to some best practices regarding the DebuggerDisplayAttribute (courtesy of Juozas Kontvainis). I think these have to be tempered with you're own justifications and awareness of how you use the types for which you're declaring display details, but these guidelines were gained from experience and are worth considering.

Okay, that was simple...

Well now the fun really starts! see my next post, Dynamic DebuggerDisplayAttribute, to find out how you can accomplish this without any code at all. And as I mentioned above, you can use the following technique to modify the inspection visibility of 3rd party types as well.

[note: attached code contains the full example solution implementing this pattern]

If you write or maintain C++ applications, you may want to leverage your (or your co-worker's) C# components - these could be visual components or logical components. You can leverage them directly, without COM enabling them or using COM wrappers! You can actually integrate them straight into your C++ application and leverage the managed assemblies as you would a project in your Visual Studio C++ solution. You can debug and step straight across the Unmanaged C++ / Managed C++ / Managed C# (or other CLR languages)

You can realize a variety of benefits:

1. You don't have to attach to multiple debugee's and jump through hoops to inspect and comprehend the state of your application and its dependencies at a given moment in real time.
2. You can debug straight through from the unmanaged WinMain down into your C# component, across each of the layers, without aggravation.
3. Your deployments will be simplified (no need to register COM components)
4. Your friends and coworkers will think you're amazingly brilliant

Its actually pretty straight foward to do this, and the results are pretty clean. I'll present some Patterns you can follow to help you achieve this, and walk through a sample app to demonstrate an implementation of the pattern:

The sample consists of:

• A native C++ windows console app project with a WinMain()
• An .h header file and a .cpp implementation file that implement a C++ to C# bridging pattern that bridges the gap from unmanaged C++ code to managed C# code
• A simple C# component containing methods and properties that we want to invoke from our native C++ console application

The Complete Solution

Generate this solution yourself in Visual Studio 2010 - invoke the File / New / Project... menu choice. In the New Project dialog, navigate to Other Languages node and click on "Visual C++" to see the list of project templates.  From this templates list, click on "Win32 Console Application". Give it a cool name like CliTest or something and put it somewhere useful in your regular PoC project location.  I named mine "CliExample"

After Visual Studio gyrates for a bit you'll end up with a new solution containing the C++ project you just added.  You'll see the initial project displayed in the Solution Explorer view - if that's not appearing for you, go to the View menu and click on "Solution Explorer".

We want to add the C# managed component now, so right-click on the 'Solution' at the top of the Solution Explorer view and choose "Add -> New Project...". You'll see the "New Project" window once again, and this time just make sure "Visual C#" is selected in the 'Installed Templates' list and then click on 'Class Library' in the list of project templates. Once again give it a cool name like 'CSharpy' or whatever.

For me, I named my projects 'Cli Example' and 'ManagedComponent'... Here's what it all looks like if you get it right.

The CliExample project is a simple C++ Windows Console Application project. The only files I've added to the template solution generated by Visual Studio 2010 are the ManagedBridge.h and ManagedBridge.cpp files.

1. The ManagedBridge.h file includes a forward reference to the managed Bridge class declared in the ManagedBridge.cpp file. This is necessary because Bridge is the boundary C++ managed class that bridges the gap between Unmanaged and Managed C++, and provides the gateway to the Managed C# (or CLR) components we wish to leverage.
2. ManagedBridge.cpp has a special compile setting: Common Language RunTime Support is set to /clr.  The rest of the project is a normal 'cplusplus' project
   
   
3. The CliExample project itself is configured for Mixed debugging – this allows you to step across the boundary and set breakpoints on both sides
   
   
4. The ClIExample project also contains a reference to the managed component – this is done via the Add Reference button at the bottom of the following dialog
   
   

The ManagedComponent project contains our (super simple) C# component. The relevant parts of this pattern are best discovered via interactive debugging and stepping through the code from the outside C++ console app all the way into the ManagedComponent class. There's subleties encountered in wiring the various classes and layers together to construct the bridge that are hard to descibe but easy to see in the code.  Here's a snapshot of the final teasingly tiny managed method that's invoked via C++ pointers and the bridge across the boundaries...

CliExample.cpp contains the main entry point for the console application, and its about as simple as it can get. But lets look at it to see what's in there.

// CliExample.cpp : Defines the entry point for the console application.

#include "stdafx.h"
#include "ManagedBridge.h"
 
using namespace ManagedBridge;
 
Bridge* ptr = NULL;
	
int _tmain(int argc, _TCHAR* argv[])
{
	ptr = new Bridge();
 
	ptr->PrintMessage("Call 1 to managed component through CLI boundary. Value should display as 0");
	ptr->SetValue(15);
	ptr->PrintMessage("Call 2 to managed component through CLI boundary. Value should display as 15.");
	
	delete ptr;
	return 0;
} 

This code is pretty straight forward: we #include the ManagedBridge.h file and declare a namespace for convenience. Then we allocate the mysterious Bridge class, make some normal looking C++ calls and then, like every good citizen, deallocate the Bridge object before terminating.  Hmmm, no rocket science here. 

But what happens behind the scenes is a bit more interesting! Within the Bridge class we allocate the MngdAdapter class (gcnew MngdAdapter) on the CLRs managed memory pool. In C++ terms this is a pointer we don't really have a reference to. Its not ours! This is a garbage collected memory footprint that we've allocated and asked for a handle to. Since it's an auto_gcroot we don't have to treat it specially. Its scope and lifetime are managed by the CLR's managed memory pool.

The instantiation of the MngdAdapter results in the allocation of the ManagedComponent instance (which is our C# component!). The adapter lives only to enable proxied calls from the Bridge to the ManagedComponent's API: The PrintMessage, SetCount, and GetCount calls.. 

So what do we see when we build and run this application?

Call 1 to managed component through CLI boundary. Value should display as 0: 
Value: 0

Call 2 to managed component through CLI boundary. Value should display as 15: 
Value 15

Let's dig a bit deeper

Earlier we referenced the ManagedBridge.h file included in CliExample.cpp.  Let's take a look inside it now:

#pragma once
 
namespace ManagedBridge {
	
	// anonymous pre-declaration of the adapter class that we'll instantiate
	// in the c++ code implementation of our class. It has to be anonymously pre-declared
	// as it's a managed class 
	class MngdAdapter;
 
	class Bridge
	{
	private:
		MngdAdapter* adapter;
 
	public:
		Bridge();		
		~Bridge();
 
		void Bridge::SetValue(int value);
		int Bridge::GetValue();
 
		void PrintMessage(const char* sMsg);
	};
};

A couple of things of note here: The MngdAdapter reference is declared anonymously with a forward reference (class MngdAdapter;). This ManagedBridge.h file is included in the native C++ ManagedBridge.cpp implementation. As a result of the compiler settings for the CliExample.cpp file, it is compiled natively. This is so important that you should spend time making sure you get what I'm saying - look at the code and examine the modified compiler settings.  Comment on this post if you think I can be clearer! 

Remember, our intention is to build a bridge from the unmanaged to the managed code, so the Bridge class is fully defined giving us an API we can use in the unmanaged native code, with the assumption that it will bridge the gap for us.

As you'll soon see we define the MngdAdapter class in the associated implementation file (fully declared obnoxiously in the ManagedBridge.cpp).  Thus we just use the forward reference and ask the compiler to trust us that it will be defined before linking commences. Both of these classes end up proxying calls into the managed components, though you could look at either like a facade in a richer example as there's no necessity that the bridge and or coupler proxy calls to a single managed component.

// ManagedBridge.cpp implementation file with definition of 'MngdAdapter' class mysteriously referenced
// in the ManagedBridge.h file with a forward reference

#include "stdafx.h"
 
#include "ManagedBridge.h"
 
 
#include <msclr/auto_gcroot.h>
using msclr::auto_gcroot;
 
#using <System.dll>
using namespace System;
using namespace ManagedComponent;
 
namespace ManagedBridge {
 
	///
	// adapter needed to hide clr stuff from our main .h file so client app 
	// code can compile cleanly; Provides adapter to the CSharp component
	// that we wish to interact with
	///
	public class MngdAdapter
	{
	private:
		auto_gcroot<MngdComponent^> adapter;
 
	public:
		MngdAdapter() : adapter(gcnew MngdComponent()) {}
 
		int GetValue()
		{
			return adapter->Value;
		}
 
		void SetValue(int value)
		{
			adapter->Value = value;
		}
 
		void PrintMessage(const char* sMsg)
		{
			adapter->PrintMessage(gcnew String(sMsg));
		}
	};
	
	///
	// Bridges Unmanaged to managed code - uses a adapter to thunk the gap
	///
	Bridge::Bridge() 
	{
		adapter = new MngdAdapter();
	}
		
	Bridge::~Bridge() 
	{
		delete adapter;
	}
 
	int Bridge::GetValue()
	{
		return adapter->GetValue();
	}
 
	void Bridge::SetValue(int value)
	{
		adapter->SetValue(value);
	}
 
	void Bridge::PrintMessage(const char* sMsg)
	{
		adapter->PrintMessage(sMsg);
	}
 }

As you can see, the calls flow like this:

Console App (Unamaged : CliExample.cpp) -> Bridge (Unmanaged -> Managed : C++ ManagedBridge.h) -> MngdAdapter (Managed C++ : ManagedBridge.cpp) -> ManagedComponent (Managed C# : ManagedComponent.cs)

https://blogs.msdn.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-01-39-62/8836.CliExample.zip