Monday, January 30, 2012

Managed IStreams

Most of the time, when we want to use some unmanaged Windows feature in C#, we have a lot of work to do first. But there's a small set of types that come pre-translated, in the System.Runtime.InteropServices.ComTypes namespace. These types provide basic COM features, like activation, naming, storage, etc.

One of those types is the IStream interface, used by COM to represent a data stream. As interfaces go, IStream is a pretty good choice to be one of the few types Microsoft translates for us. In COM, an IStream is the de facto standard for sending data between COM components. And C# developers love the Stream object, for much the same reason. This sounds like a match made in heaven!

Unfortunately, there are some problems with the Framework's version of IStream that makes it harder to use that it really needs to be. Beyond that, the way COM handles streams is a bit different from the way the Framework does, making the two not-entirely-compatible. These differences make the IStream interface, as designed, less useful that it ought to be. So today, we're going to fix it.

Thursday, January 26, 2012

MVPVM: The Best of Both Patterns?

In the past few posts, we've been looking at some architectural patterns that are in common use among .NET developers, including the classic Model-View-Controller, and derivatives like Model-View-Presenter and Model-View-ViewModel. My original motivation for writing these posts, however, comes from an even newer pattern, an extension of the MVVM pattern called the Model-View-Presenter-ViewModel pattern.

Until recently, I had been using these various patterns in different projects without really thinking too much about where they came from or how they were related. I (like many other developers, I suspect) was just using the pattern that seemed to work best: MVP for my Windows Forms app, MVC for my new ASP.NET apps, MVVM for my WPF apps, etc. But as I was reading an article in MSDN magazine from December 2011, on a new pattern for WPF applications, everything semed to "click" for me, how these patterns evolved, how they were related, and why a given pattern works better than any other in a given situation.

I wrote out this series of blog posts, in part, to help crystallize this new understanding in my own mind, and in part to share it with other people who may still be unclear on what all this "pattern" stuff is all about. So, it seemed only fitting to wrap up by giving a brief overview of this new pattern, and my thoughts on it. First, though, a couple of caveats:
  1. I have never used this pattern in production, so I am in no way an expert on it. These are just my early impressions.
  2. This pattern is still fairly new -- even the name is not yet in common use. So I'm pretty confident that this pattern will evolve as people learn and understand more about it.
  3. So far, I'm not entirely convinced that this pattern is something I'll ever use, but see point #1.
  4. Because of point #1, this is going to be a much shorter post, with less code, than usual. Hopefully, as I get more acquainted with this pattern, I can come back and do a better one.
So, consider this just my first impressions and musings on an emerging idea in pattern-based development.

The Composite Application Library

The origins of this pattern, which was largely unnamed until recently, was the Microsoft Composite Application Guidance, also known as the Prism project, which was designed to guide developers writing enterprise-level WPF applications. It takes advantage of other Microsoft frameworks, like Unity or the Managed Extensibility Framework, to combine loosely-coupled elements of your application in various ways at run-time.

Although the guidance talks a lot about the MVVM pattern, if you look closely, you'll see that the actual pattern  is not a typical "triad", like the other patterns we've looked at. Instead, there is a fourth component included in the mix, which is used to coordinate among the other three. For lack of a better term, this component is called a Presenter, since it behaves much like an MVP Presenter is supposed to.

One of the key aspects of Prism is that every element in the application is very loosely coupled to the other elements. Prism uses various techniques at run-time to bind those elements together in combinations as needed, so the elements themselves must be highly reusable and flexible. One of the flaws in the MVVM pattern is the tight binding between the View and ViewModel, especially once your ViewModel starts asking for user input (confirmation dialogs, etc.)

Splitting the View and ViewModel

This is where the MVPVM pattern comes into play. Its target audience is very large-scale enterprise applications where multiple views, with different business requirements, may need to bind to the same ViewModel, which means your ViewModel cannot include view-specific business logic. It also means you will definitely be doing extensive unit testing and coded UI testing of your components, so you need that process to be as efficient as possible.

Here is one place that I start to lose the thread of why this new pattern is really necessary for my purposes. To quote Bill Kratochvil (author of the referenced article) on why this new pattern is needed:
If you have to put code in your WPF code-behind, for any reason, then you've run into a limitation of MVVM alone;  a limitation that will prevent reuse, prevent proper unit testing and cause code bloat. --
(An interesting note from that blog post, that I missed in my original MVP and MVVM posts, is that MVVM is really just a new name for an old pattern, the PresentationModel pattern, updated and enhanced for WPF). But the key here, IMO, is this contention that any WPF code-behind at all represents a serious flaw in your architecture. To me, that's just silly, and represents a strange belief that the code-behind is somehow a separate and independent component of the system. To me, the code-behind class behind a WPF Page or UserControl is part of the View: anything I would logically be able to place in the View I can just as logically place in the code-behind. Obviously, there are a lot of benefits to keeping the code here small and letting WPF do the work, but something like this, for example, represents a perfectly natual use of code-behind for me:
private void DataContextChanged(object sender, DependencyPropertyChangedEventArgs e)
    var old = e.OldValue as TransactionTenderWindowViewModel;
    if (old != null)
        old.ValidateOperation -= ValidateOperation;

    var value = e.NewValue as TransactionTenderWindowViewModel;
    if (value != null)
        value.ValidateOperation+= ValidateOperation;

private void ValidateOperation(object sender, ValidateOperationEventArgs e)
    var message = string.Format("Please confirm that you really want to {0} your {1}.", e.Operation, e.Target);
    var result = MessageBox.Show(message, "Validate Operation", MessageBoxButton.OKCancel, MessageBoxImage.Information);
    e.Cancel = (result == MessageBoxResult.Cancel);
Here, my ViewModel is firing an event that says "any Views that are listening to me, if you don't want me to Operation my Target, now's your chance.".

Under the MVPVM model, this code would instead belong in a Presenter class that handles this validation for the views that need it, and ignores the validation for views that don't care. In this model, it is only the Presenter that has any tight coupling to other components: it is bound to a View, a Model, and a ViewModel, and ferries information and operations between the three. This is a Supervisory Controller style Presenter: the View and ViewModel still have some direct data binding, but complex operations are offloaded to the Presenter. The following diagram from the MSDN article shows these relationships (note that the business and data logic, and domain models, all fall under the Model aspect of this pattern):

The MVPVM Architectural Pattern

Of course, the problem here is that the target environment for this pattern are applications on a far larger scale than anything I typically have to deal with. (I don't think I've ever seen the kind of application that Prism considers "enterprise-level", based on their description). The focus of the MVPVM pattern isn't simply to get code-behind out of the View, but to get view-specific logic out of the ViewModel, to make the entire application modular, scalable, and testable.

Kratochvil uses an example of a set of search results screens, all using the same underlying ViewModel, where some views display a certain field and other don't. Instead of polluting the ViewModel with the knowledge of its parent View and logic to set/clear the field's visibility, that logic is moved into a Presenter that coordinates between the two, now decoupled View and ViewModel objects as needed.

Now, in my understanding of the MVVM pattern, it is not common practice to reuse a ViewModel for multiple Views. In the above scenario, there would simply be more than one ViewModel, possibly with the common operations refactored into a base class. (Arguably they may also belong in the Model itself.) However, as your application scales in size, having lots of redundant ViewModels can become a problem. This is particularly true if your application has Views for lots of different target environments (web, client, mobile, etc) that are slightly different in their requirements: maybe none of your mobile Views are allowed to see social security numbers, or something.

Final Impressions

Overall, I'm still getting familiar with this pattern, so take these comments for what they're worth. When I started reading about this pattern, my first thought was an old programming adage:
All problems in computer science can be solved by another level of indirection -- David Wheeler
That clearly seems to be what's going on here: the pattern is solving the "problem" of having tightly-bound View and ViewModel classes by adding an indirection layer between them. The second thought I had was (with sincere apologies to Jamie Zawinski):
Some people, when confronted with a problem, think "I know, I'll use another level of indirection." Now they have two problems.
One of the biggest complaints about the MVVM pattern is that it's adding too much overhead, for too little benefit, to what is already a complex framework (WPF). This pattern takes that overhead and layers on another pile of overhead, for arguably even less benefit.

My impression here is, if you are actually writing an application where the Prism library and guidance can be useful for you, the runtime overhead of adding a Presenter to MVVM will be swallowed up in the noise. And the benefits you gain from testing efficiency and responding to changing requirements will probably add up to a major net gain over the added development complexity. But for me, for now, MVPVM is staying on my shelf as one of those ideas that never found a need for.

Tuesday, January 24, 2012

The MVVM Pattern: MVP Evolved

So far, we have taken a close look at two of the architectural patterns in the Model-View-Whatever family, the MVC and MVP patterns. These patterns both enjoy widespread use across platforms, languages, and runtime environments, and are both still in heavy use.

Today, we're going to look at a pattern that is somewhat more specialized, and at least at this point, primarily finds use in WPF applications: the Model-View-ViewModel pattern. MVVM is a natural evolution of MVP that takes advantage of WPF's features, as we'll see in a minute. But first, what is MVVM and how did it develop?

Saturday, January 21, 2012

The MVP Pattern: Son of MVC

Last time, we starting looking at the concept of architectural patterns, and how they are used in software development. We also traced the history of the prototypical architectural pattern, the Model-View-Controller or MVC pattern, from its Smalltalk roots in 1979 through 3 decades of progress, to modern MVC frameworks, like Ruby on Rails or ASP.NET MVC.

But MVC isn't the end of the story, not by a long shot. Besides evolving into new versions of itself, the MVC pattern has also spawned an array of alternative patterns. These patterns take the same core concept, separation of concerns at a fundamental architectural level, and just reorganize where all the pieces go.

Today, we'll take a look at some of the common elements of this family of patterns, then examine one  of those variations in more detail: the Model-View-Presenter or MVP pattern.

Tuesday, January 17, 2012


One of the things I and my colleagues at my $DAYJOB have been dealing with on our current project is understanding a popular WPF architectural pattern called the "Model-View-ViewModel" pattern, or MVVM. It is the latest in a growing trend of alphabet soup coming out of the .NET developer's community. For myself, and I suspect many others, it is sometimes a struggle to understand what all the fuss is about, and why I should waste my valuable development time learning some new technique that will just disappear when the next big thing comes along.

Much of the problem is that these new design patterns seem to require me to write code in a dramatically new and different way than I am used to, without providing any real, tangible benefits for doing so. Worse, these concepts seem to be coming out of nowhere, with no background or foundation behind them, and immediately being touted as the next great thing in software development. Recently, however, I have had an epiphany of sorts. Not really anything so dramatic, but a number of things seemed to "click" for me in a way they had not before.

For many of you, particularly if your background is not Windows desktop development in C/Delphi/VB/C#, some of this will be like going back to grade school. However, I suspect I'm not the only one overwhelmed by all these big ideas, so I'm going to try and explain the concepts behind these "new" techniques, at least how I understand them, for the benefit of anyone else that's struggling to figure them out.

Friday, January 13, 2012

Hungarian Notation and Interop Code

Those of you without a lot of pre-.NET programming experience may have noticed the very bizarre names used by the various Windows SDK functions, interfaces, and types we looked at during the COM interop series. You may be wondering what, if anything, those cryptic jumbles of letters meant.

The short answer is, they are called Hungarian Notation (a reference to the proper name style used in Hungary, the native country of the developer who invented it), and it has largely fallen out of favor. You can get into some very vicious arguments with long-time developers by simply declaring your love/hate for it. Personally, I don't like to use it simply because it clashes with the current prefix-free style of C# naming conventions.  I have already mentioned my preference for translating structure names into friendlier names; I generally do the same thing for fields and parameters as well (but, somewhat arbitrarily, not interfaces or functions... see below.)

The longer answer is much more interesting, and somewhat of a tragedy, in that something with the potential to be very useful was misused to the point of meaninglessness. If you're interested in the details, read on...

Wednesday, January 11, 2012

COM Interop Part 10: Recapping And Wrapping Up

Wow, this turned out to be a much bigger series that I originally planned, but we covered a LOT. To wrap up, I want to just summarize some of the most important information we've covered so far, in preparation for future posts where we do cool things with COM Interop. Consider this something of a cheat sheet for interop translations.

Monday, January 09, 2012

COM Interop Part 9: Custom Activations

So far, we've seen how to activate a single instance of a COM object, both locally and remotely, using CoCreateInstance or CoCreateInstanceEx. But there are many other ways to get a COM object activated, some of which allow us to do pretty interesting things. Today, to finish out this introductory series on COM interop, we're going to take at those other methods: CoGetClassObject, DllGetClassObject, and custom SDK functions.

Friday, January 06, 2012

COM Interop Part 8: Strings, Arrays and Structures

In the last installment of this increasingly long series, we saw how to activate a new COM object for the first time on a local machine. One of the features of COM programming (and a big deal at the time it first came out) was the fact that remote, or "distributed", COM programming was almost as easy as local programming: all the complex work was handled by DCOM and the client could largely ignore the distinction.

Activating remote COM servers through COM interop turns out to be almost as easy as activating local ones. Translating those methods properly, however, means digging into some new details of the data marshalling logic: arrays, strings and structures. We're starting to get into the really good stuff here, but it's a lot to take in, so hold on tight and lets get to it.

Wednesday, January 04, 2012

COM Interop Part 7: COM Activation

So far in this series, we have focused on how to translate the methods of a COM interface. To fully exploit the power of interop, however, we need to understand a couple more types of native code element: structured types, enumerations, and functions. (For clarity, from here on out, when I say "function" I mean a native non-COM function, as opposed to a "method" which is part of a COM interface.) Windows-provided COM components make frequent use of all of these elements, so it's important that we understand the rules for those as much as the COM interfaces themselves.

This time, we're going to focus on native function calls. These are accessed via an interop mechanism called "platform invoke", or P/Invoke, which is subtly different than COM Interop. For the most part, P/Invoke calls are used to deal with part of the Windows API that are not based on COM, particularly the kernel itself, the GDI engine, and the windowing system. However, the COM-based SDK components also expose a small, but critical, number of P/Invoke calls that we need to use. To start off, we're going to take a look at the P/Invoke methods that do something we've kind of glossed over up until now: give us an initial reference to a new COM instance.

Monday, January 02, 2012

COM Interop Part 6: IUnknown and RetVal Rewriting

Today, we're going to finish out the definition of IUknown that we started last time, by adding the three methods to the interface. While it's a very simple interface, compared to some of the others we'll get to later, it does highlight a number of interesting and important behaviors that the runtime marshaller exhibits when calling a COM interface.

[Edited 1/3/2012 to include information about how the runtime translates is/as into QueryInterface].

COM Interop Part 5: Translating IUnknown For Fun And Profit

Well, probably not much profit, but hopefully a little fun.

As promised, this time we're going to write some actual C# interop code. A major downside to learning COM Interop is that there isn't an obvious place to "start small". You basically have to get all of the details right all at once, or things can go catastrophically wrong. Unfortuantely, that means the first few posts will have to include some things that might not make sense right away. Bear with me on this, we'll cover it all eventually.

When starting out to use COM Interop, I typically follow the same basic steps to get from idea to working code.
  1. Identify a COM interface I want to use, and whatever native functions I need to get it.
  2. Locate the IDL or header file in the SDK with the appropriate definitions.
  3. Locate the documentation for the interface or function.
  4. Start translating the interface from IDL
  5. As I encounter additional interfaces, types, etc., repeat steps 2 through 4.
The first step is sometimes the hardest, because Windows has a lot of interfaces available that do some pretty cool things. As you can tell, MSDN is a treasure trove of information here, and is usually where I start. The MSDN page for a function or interface will also tell you what IDL and header files to look in, and describe the intended behavior (the "contract") for the interface. With those two things, we have everything we need to start translating.

So, lets do one. I'm going to start with a relatively simple interface, just to show you how things go. Much of this is boilerplate stuff, so every COM interface you translate will start off the same. The interface we'll be looking at is the same one from last time, IUnknown.

COM Interop Part 4: A Look at IDL

Last time, I promised we would get to some real code. That was only slightly a lie: there's code in this post but it's not C#. Instead, I wanted to talk about one more aspect of COM development that we'll be seeing a lot of, once we get started.

COM Interop Part 3: Every Day I'm Marshalling

(I apologize profusely for the title, but I have that song stuck in my head.)

So far in this series, we've seen what COM Interop is, what it's used for, and why we might want to tackle the job of writing interop code on our own. Before we can get started, though, we need to understand a little bit about the inner workings of interop. The whole process relies very much on everyone knowing and following the rules; if you do, things work great. If you don't, you end up with nearly impossible-to-troubleshoot bugs. The CLR tries to shield you from as much of this as possible, but as always, knowing what's going on is better than flying blind.

COM Interop Part 2: Interop The Easy Way

Last time we got a brief introduction to interop, and in particular COM Interop, and why we might need to use it. The idea of using C# to talk to a non-C# application sounds like it could be a lot of work, and rife with potential bugs. Mostly because it is. Once you leave the safe, cozy confines of a managed environment, we open ourselves up to all kind of errors that managed code left behind a long time ago. Fear not: avoiding these errors is a simple (!) matter of understanding the rules of interop, and following them religiously.

COM Interop Part 1: An Intro to Interop

For those of you who are unaware, I spend most of my time at my $DAYJOB developing software in C#. Managed code is awesome for oh so many reasons, which I won't get into here, but there is one serious drawback when it comes to writing Windows applications in C#: Windows itself is not written in managed code.

In other words, there's almost 20 years worth of existing Windows features, APIs, etc. just waiting for me to use them, and I can't talk to them from C#.

Of course, Microsoft knew this was going to be a problem.  Its a problem they have to deal with themselves, since large chunks of the .NET base class libraries are just exposing Windows features to managed code. So, built into the .NET Framework is the concept of unmanaged code interoperability, or "interop". This is the part of the Framework that allows existing, unmanaged code and new, managed code to cheerfully coexist, even in the same process.

Anyone got a copy of blogging for dummies?

Somehow my blog posts ended up out of order; I'm gonna try to fix it but apologies for anyone that got confused. (Also, it will probably look like 6 posts went up at the same time; oops.)