Read the rest at https://mattdotson.com/making-microsoft-vsts-cmmi-estimate-field-reportable-in-tfs/

We’ll tackle ObservableModel first since it’s the root of our implementation.  ObservableModel provides a base class which actual models can inherit to automatically get notification of changes to the data in the model.  ObservableModel does this by supporting the INotifyPropertyChanged interface which WPF knows to listen to for the PropertyChanged event. 

This is the same interface that DependencyObject implements, so some might ask “Why don’t we build ObservableModel on DependencyObject?”  Well, it turns out I thought about this.  My first attempt at a PM implementation was based off of DependencyObject (DO from now on), but I quickly found out that some of the more advanced services I wanted to offer were difficult to implement because DO abstracted so much away from me.  One of the best examples of this was Undo/Redo.  To implement this, I really wanted to control how property values were stored, but DO hides this from inheritors. I didn’t want to completely hijack DO, so I eventually resolved to create my own set of classes. 

Implementing INotifyPropertyChanged requires that we raise an event whenever a property changes on an object inherited from OM, but how do we know when a property changes?  We don’t really want our inheritors having to raise the event explicitly in every property setter, so we’ll do the same thing DO does, we’ll implement GetValue and SetValue methods.

That’s about all we need right now. While there are a lot of interfaces we will eventually add to our ObservableModel class, we’ll just implement INotifyPropertyChanged for now.

Now that we have the basics down, let’s create PresentationModel.  Our PresentationModel class needs the same features as ObservableModel, fortunately we thought about this ahead of time, and we are just going to inherit PresentationModel from ObservableModel.  We need to add a few more things to PresentationModel though.  First off, we want to be able to initialize our PM with data.  We could do that in the constructor, but there is a better option: ISupportsInitialize.  While there are two methods to control initialization on this interface, we are going to abstract those from our inheritors, and create an abstract method called Initialize().  This is where our inheritors are going to begin getting data for their screen. 

We also need one more thing: CommandBindings.  In order for our PM to accept commands from the View, we need to have some way for the View to figure out which commands we support and send us those commands.  To do this, we’ll create a CommandBindings property which will be filled up by our inheritors.  The View will add this to the Page’s CommandBindings property so commands are automatically forwarded to us from WPF.

Now we have the basics setup.  For good measure we are also going to create ObservableModelCollection.  Why can’t we just use ObservableCollection?  Well for one, there are a bunch of UI Controls (Infragistics in particular) which don’t do a good job of listening to events on sub-models, so we want our ObservableModelCollection to listen to those events and forward some of them up.  Secondly, we are going to need this when we eventually implement Undo/Redo.  ObservableCollection is a good start though, so we’ll use this as our base class and add the event forwarding.

That’s all for now, in part 3 we’ll create a model/view pair which uses these base classes.

1. Reflector (https://www.aisto.com/roeder/dotnet/) - If you only get one tool, this is the one to choose.  Decompile any .NET code.  I can't even count the number of times I've been able to figure out why I'm getting some random exception back from a system function with this tool.  It also faster to use than the .NET documentation, so I use it to lookup API's.  Do I need to call Dispose and then Close, or does Dispose call Close, now I know.
   
   
2. Rhino mocks (https://ayende.com/projects/rhino-mocks.aspx) - I can't imagine unit testing without rhino.
   
   
3. Snoop (https://www.blois.us/Snoop/) - Do you develop WPF apps. This visual tree tool will help you figure out how to restyle almost anything.
4. Wireshark (https://www.wireshark.org/) - Nothing beats this network sniffer
5. TFS Sidekick (https://attrice.info/cm/tfs/) - All those things you wish TFS did, sidekick does.
6. Stylus Studio (https://www.stylusstudio.com/) - hands down the best XML tool on the planet.
7. The Regulator (https://tools.osherove.com/CoolTools/Regulator/tabid/185/Default.aspx) I love regular expressions, but they can a nightmare to debug.  This tool makes it regex trial and error fast and easy.
8. Ghost Doc (https://www.roland-weigelt.de/ghostdoc/) - I like writing code, I don't like writing comments. I like ghost doc.
9. Sandcastle (https://blogs.msdn.com/sandcastle/) - Again, I like writing code, I don't like writing docs.  Make professional looking documentation from your code.
10. Process Monitor (https://technet.microsoft.com/en-us/sysinternals/bb896645.aspx) What the heck is locking that file? ProcMon knows.

Of course it goes without saying that Visual Studio is the tool that I use most.  But there are a bunch of things in Visual Studio that take beginners some time to figure out. If you don't know what these are, go figure them out now!!

1. The immediate window - I wish it was more robust, but what it is now is pretty powerful.
2. Auto format/ auto indent
3. Refactoring
4. Code snippets
5. Automatic "using" statements
6. Conditional breakpoints
7. Profiler
8. Code analysis
9. Move to last position (CTRL -)
10. Incremental Search
11. Find and Replace with Regex
12. Flagging threads in the thread window

These are just a few things I use to get my job done.  If you don't know what any of these tools or VS features are, I encourage you to try them out.

Many applications use Forms & Controls pattern for their user interface.  This is partially because it is the default pattern Visual Studio uses to create an application and more likely because it is a very simple pattern with a low barrier of entry for developers.  Though Forms & Controls approach may be simpler to implement for small applications which can get away with limited or no unit testing, larger and more complex applications are increasingly difficult to maintain using this approach.  This inherent lack of testability of a Forms & Controls pattern make is a poor choice for implementing larger applications.

To solve this problem of testability, software architects have turned to more advanced user interface patterns such as Model-View-Controller, Model-View-Presenter (a.k.a. Supervising Controller and Passive View), Presentation Model, and other variants of these patterns.  The goal of these patterns is creating user interface classes which can be easily tested, and minimizing the amount of code which resides in the view (a notoriously difficult part of the application to test in an automated fashion).  Though these patterns are technology independent, the underlying GUI framework lends itself to certain patterns.  Windows Forms technology meshed particularly well with the Model-View-Presenter pattern, while implementing a Presentation Model pattern in Windows Forms required masses of synchronization code.  Windows Presentation Foundation, on the other hand, fits very well with the Presentation Model because of its advanced data binding technology which eliminates the need to write masses of synchronization code between the view and presentation model. 

Each screen is implemented as a View and Presentation Model pair.  Each class has distinct responsibilities.  The view is responsible for how data is presented on the screen, and the presentation model is responsible for what gets presented on the screen and the actions which can be performed on that data. 

The view consists of both the XAML and the code-behind, and displays the data it gets from the presentation model.  Most views will be implemented mostly in XAML with a little supporting C#.  Layout and user interaction are the primary responsibilities of the view.  The view interprets user actions and forwards them to the presentation model as commands. 

Commands are used to invoke behavior.  The command pattern decouples the presentation model from the actual input event which invoked some functionality.  Commands capture the intent of the user, not necessarily the actual mechanics of how they indicated that intent.  For example, the presentation model doesn’t need to know if the user clicked the save button, pressed CTRL+S, or selected save from a menu option.  All the presentation model needs to concern itself with is that the data should be saved.  The command object also provides a good mechanism for the presentation model to indicate if an action is enabled through the CanExecute callback of the command.

While the PresentationModel receives communication from the View via Commands, if it needs to notify the View of something, it should use events.  Events allow us to define the means of communication on the presentation model itself.  While some events should be built into the presentation model base class (notifying when properties changed), others are screen specific and should be in the screen’s presentation model.  There is no separate interface implemented by the View as in MVP.  Having the presentation model provide events simplifies unit test code, because you don’t need to create dummy views.

We’ll cover more in part 2.

Background Info:

Windows exposes several types of synchronization primitives (Mutexes, Events, etc.), but in .NET 1.1 we were limited in our use of them.  Sure, we had AutoResetEvent and ManualResetEvent, but the framework did not expose the "named" version of these.  In case you were wondering, the "named" version allows us to share an event between two (or more) processes.  The name makes it easy for multiple processes to say "give me 'EventA' "!!  So before 2.0, we had pretty good support for synchronization within a process, but not very good support across processes.  Yes, in .NET 1.1, we could get to this functionality using PInvoke, but it could get complicated quickly because you can attach security descriptors to an event.  And anyone who has tried to PInvoke to set some ACLs can tell you that security descriptor is a beast that you don't want to be playing with in C#.  Fortunately this has been remedied in the 2.0 framework, and the Access Control Lists are now 1st class .NET objects.  I am going to go out on a limb and speculate that this is why named events were not included in the first version of the framework.

Back on Track:

"Great!" you say, but what the heck does this have to do with EventWaitHandle?  Well, EventWaitHandle is .NET 2.0's implementation of events -- both named and unnamed.  You can see that ManualResetEvent and AutoResetEvent now inherit from EventWaitHandle.

So, let's get started and see what we can create with this.  In this example, WorkerA does some work, which notifies WorkerB who begins some work, which notifies WorkerC to finish up some work.  You can see that we are creating a simple pipeline.  (A real pipeline would keep working, but ours just exits after one iteration).

Let's start by providing some tools for these events to get access to the events.

public static class NamedEvents

{

    public static EventWaitHandle OpenOrCreate(string name, bool initialState, EventResetMode mode)

    {

        EventWaitHandle ewh = null;

        try

        {

            ewh = EventWaitHandle.OpenExisting(name);

        }

        catch (WaitHandleCannotBeOpenedException)

        {

            //Handle does not exist, create it.

            ewh = new EventWaitHandle(initialState, mode, name);

        }

        return ewh;

    }

    public static EventWaitHandle OpenOrWait(string name)

    {

        EventWaitHandle ewh = null;

        while (null == ewh)

        {

            try

            {

                ewh = EventWaitHandle.OpenExisting(name);

            }

            catch (WaitHandleCannotBeOpenedException)

            {

                Thread.Sleep(50);

            }

        }

        return ewh;

    }

}

We've provided the tools to create an event if it doesn't already exist or open it if it does, and to open an existing event or wait for it to be created.  Unfortunately there is not a good way to "test" if an event exists, so we just have to catch WaitHandleCannotBeOpenedException.  Here is our code for WorkerB, though the other workers are almost identical except that they set and wait on different events.