Brian Genisio's House of Bilz

Prism Slides and Demo

Brian Genisio's House Of Bilz — Fri, 12 Mar 2010 11:50:37 GMT

I recently gave a presentation on Prism at the Ann Arbor .Net Users Group. I have made my slides and demo available for download:

Slides Demo

Some interesting links associated with prism:

Composite Application Guidance
Composite Application Library
Codeplex Site
Great 4-part video series
Another video series that David Giard pointed me towards

MVVM Jam – A Solution

Brian Genisio's House Of Bilz — Wed, 03 Mar 2010 03:08:08 GMT

Thanks to all who came to the MVVM jam tonight. In case you wanted to see what a completed solution looks like, you can download it here. There are many tweaks that can be made, and it is certainly not the only solution… but hopefully, it helps to understand how the MVVM pattern can be applied.

Next week (Wednesday, March 9th) , I will be giving a presentation on Prism for Silverlight and WPF at the Ann Arbor .Net Users’ Group. It is an eyes-forward talk about more patterns similar to MVVM.

MVVM Jam -- Prerequisites

Brian Genisio's House Of Bilz — Sun, 28 Feb 2010 02:45:49 GMT

For those in the Ann Arbor, Michigan area, you might be familiar with the “Come Jam With Us” project. Every week, we get together for an hour and code on a particular topic. It is usually led by one or two people and the rest of the group codes along in order to learn about the topic at hand. It is a really great forum for learning new concepts and technologies.

This week, on Tuesday, March 2nd, I will be hosting an MVVM jam session at 5:30 (directions). I will be taking you through the process of transforming a “Ball of Mud” application to use the MVVM architecture. We will do this in a test-driven way, so you can see the testability story of MVVM.

The prerequisites are very simple:

1. Visual Studio 2008 or 2010 or Visual Studio Express (free)

2. Download the sample project. It is a rudimentary Twitter search application written with WPF.

3. You should have some way of running NUnit tests from Visual Studio. If you have ReSharper or TestDriven.Net (or any similar plug-in), then you are all set. ReSharper has a free 30 day trial and TestDriven.Net has a free version for personal use.

I hope to see you there!

Goodbye XML… Hello YAML (part 1)

Brian Genisio's House Of Bilz — Sun, 21 Feb 2010 18:32:38 GMT

This is the first in a many-part series in which I will be writing about using YAML in the .Net space – particularly within C#. I will cover the whys, the hows, and show some tricks using the dynamic capabilities of C# when using YAML. I might even explore IronRuby a bit.

Why YAML?

I got the chance to sit in on four days of Ruby on Rails (RoR) training from Joe Obrien a few weeks ago. I hadn’t played with RoR in a few months, and this training was amazingly useful. I always like to see what I can take away from an environment like this for the work I do more regularly.

In this case, one of the things I took away with me was YAML. Let me start with some background.

Over 10 years ago, when XML was touted as a human-readable data format, I had to scoff. Was XML really human readable? Well, from a software developer’s perspective, it sure is a lot nicer than binary. But, from a REAL human’s perspective, XML is just barely more readable than Klingon. This is mostly due to the verbose nature of XML and the often ranted about “angle bracket tax”.

10 years later, we are still using XML as our primary data transfer/persistence/definition format. I certainly don’t mind using XML in a world where I (a human) rarely need to read the data. I am fine with keeping the data in my REST services as XML, for instance. In that case, my tools abstract it away and I don’t have to read it very often.

Currently, my colleague Mike Woelmer and I have a client who needs us to develop an engine where the business rules will be entered by a human (not a developer) and will change as the project evolves. The data/rules will be set in stone once the project is complete. XML is a bad choice for this, since a non-technical person will be entering the rules. At the same time, developing a UI for this is too time consuming and out of the scope of the project. My first thought: a Doman Specific Language (DSL)! That would certainly lend well to my requirements. As much as I liked that idea, I didn’t have time to create a DSL either, especially while spiking. Then I remembered back to my RoR training. I remembered a data format called YAML that they used for some of the configuration files. It was a VERY easy-to-read, hierarchical data format.

To illustrate the difference between XML and YAML, here is a simple example of some rather easy-to-read XML defining the data for a recipe (unrelated to my current project):

<recipe>
  <title>Macaroni and Cheese</title>
  <description>My favorite comfort food.</description>
  <author>Brian Genisio</author>
  <timeToPrepare>30 Minutes</timeToPrepare>
  <ingredients>
    <ingredient>
      <name>Cheese</name>
      <quantity>3</quantity>
      <units>cups</units>
    </ingredient>
    <ingredient>
      <name>Macaroni</name>
      <quantity>16</quantity>
      <units>oz</units>
    </ingredient>
  </ingredients>
  <steps>
    <step>
      <number>1</number>
      <description>Cook the macaroni</description>
    <step>
    <step>
      <number>2</number>
      <description>Melt the cheese</description>
    </step>
    <step>
      <number>3</number>
      <description>Mix the cooked macaroni with the melted cheese</description>
    </step>
  </steps>
</recipe>

Here is the exact same data described with YAML:

Recipe:
  Title:         Macaroni and Cheese
  Description:   My favorite comfort food.
  Author:        Brian Genisio
  TimeToPrepare: 30 Minutes
  Ingredients:
    -
      Name:     Cheese
      Quantity: 3
      Units:    cups
    -
      Name:     Macaroni
      Quantity: 16
      Units:    oz
  Steps:
    -
      Number: 1
      Description: Cook the macaroni
    -
      Number: 2
      Description: Melt the cheese
    -
      Number: 3
      Description: Mix the cooked macaroni with the melted cheese

Although this is a very simple example, I would ask you: Which one would you rather present to a customer when talking about the data and business rules? Which one would YOU rather look at when developing your software?

In my next couple of posts, I will discuss some tools available to you in the .Net space and some nifty C# 4.0 techniques for working with the data.

Adventures in MVVM – CodeMash Schedule Application

Brian Genisio's House Of Bilz — Tue, 12 Jan 2010 02:59:13 GMT

More Adventures in MVVM

So, I am getting myself ready to head out to Sandusy, Ohio for three days of nerdy fun at CodeMash. While I am there, I will be giving my “Introduction to the MVVM Pattern”. In preparation for this talk, I decided to create a new demo application. This application is a calendar and session list for the conference. It is not terribly fancy (I wish I had more time (or talent) to skin it better), but it highlights many of the concepts that I will be speaking about in my presentation.

The app is a Silverlight 3 project utilizing the Telerik Scheduler control. This particular control is rather rich, and I was excited to get my hands dirty with it. The ViewModel for the scheduler was primarily responsible for translating session data into something the Telerik control could consume. The app also includes a session list with a filter panel which is derived from the session data. This is where the majority of the MVVM code can be found. The ViewModels for the session list are responsible for dynamically creating and merging filter predicates based on the values in the session list.

You can play with the application at http://HouseOfBilz.net/CodeMash

CodeMashSessions Source Code: http://www.houseofbilz.net/codemash/CodeMashSessions.Source.zip

Twitter "Ball of Mud" vs MVVM Source Code: http://houseofbilz.net/codemash/Twitter-BallOfMud-vs-MVVM.zip

Slides from "An Introduction to the MVVM Pattern": http://houseofbilz.net/codemash/MVVM.ppt

Moving On

Brian Genisio's House Of Bilz — Mon, 21 Dec 2009 03:39:43 GMT

Four years ago, I moved to Ann Arbor to work with a talented team on what I consider to be an important, high-quality medical application. In that time, I had many great opportunities and I learned a ton from my colleagues. My team is filled with some really smart people! Because of this, I have mixed feelings to announce that I am moving on. Starting in February, I will be working for Bill Wagner and Dianne Marsh and joining the team at SRT Solutions. It will be quite a change for me -- moving from one of the largest companies in the world to a small, local consulting company. This job will, however, give me an opportunity to spend more time focusing on the technologies and concepts that most interest me. I am excited for this change, and I am excited to be working directly with the many amazing members of the SRT team.

Adventures in MVVM -- Dependant Properties with INotifyPropertyChanged

Brian Genisio's House Of Bilz — Sun, 15 Nov 2009 01:55:41 GMT

More Adventures in MVVM

I spend a lot of time writing ViewModels, which almost always implements INotifyPropertyChanged. For those who are not familiar with this interface, it includes a single event: PropertyChanged. That event contains a payload of the name of the property that changed. It exists as a standard way to notify observers that a property needs to be re-evaluated.

Although I use it all the time, I have always believed that INotifyPropertyChanged has some serious shortcomings. One of those shortcomings deals with dependant properties.

Lets say, for for the sake of example, that the ViewModel has two integer properties that the user can enter (InputA and InputB). There also exists a property named Calculation that is dependent upon InputA and InputB. Finally, there is a display property named CalculationText which is dependent upon Calculation. The code for these properties would look like this:

private int _inputA;
public int InputA
{
    get { return _inputA; }
    set
    {
        if (_inputA == value) return;

        _inputA = value;
        RaisePropertyChanged("InputA");
        RaisePropertyChanged("Calculation");
        RaisePropertyChanged("CalculationText");
    }
}

private int _inputB;
public int InputB
{
    get { return _inputB; }
    set
    {
        if (_inputB == value) return;

        _inputB = value;
        RaisePropertyChanged("InputB");
        RaisePropertyChanged("Calculation");
        RaisePropertyChanged("CalculationText");
    }
}

public int Calculation
{
    get { return InputA * InputB; }
}

public string CalculationText
{
    get { return "A * B = " + Calculation; }
}

There is a problem with this code. The input properties need to know that they are inputs for Calculation and CalculationText by firing the event for the calculations. As far as I am concerned, this is the wrong place for this information to exist. Inputs should not know that they are inputs. I can say first hand that this quickly breaks down as the ViewModel gets bigger and you start changing behavior.

The responsibility should be reversed. Instead of having the input properties knowing about the dependants, the dependent properties should be responsible for knowing the inputs that they rely upon. This can be done with some simple declarations:

private int _inputA;
public int InputA
{
    get { return _inputA; }
    set
    {
        if (_inputA == value) return;

        _inputA = value;
        RaisePropertyChanged("InputA");
    }
}

private int _inputB;
public int InputB
{
    get { return _inputB; }
    set
    {
        if (_inputB == value) return;

        _inputB = value;
        RaisePropertyChanged("InputB");
    }
}

[DependsUpon("InputA")]
[DependsUpon("InputB")]
public int Calculation
{
    get { return InputA * InputB; }
}

[DependsUpon("Calculation")]
public string CalculationText
{
    get { return "A * B = " + Calculation; }
}

Notice how Calculation declares that it is dependent upon InputA and InputB. CalculationText also declares a dependency upon Calculation. The inputs are free of knowing anything about the dependants.

The implementation of this behavior should be handled in the base class and there are several ways to accomplish it. There are just a few things you want to think about:

Make sure that when inputs fire a change notification, the dependants are also fired
Make sure to handle dependency chaining. InputA will cause Calculation to fire and Calculation will cause CalculationText to fire
If the derived class declares dependencies such that it creates a circular reference, don’t endlessly loop or overflow your stack

Here is a very simple implementation of this behavior. It manages the reflection at the time of change. A better (more efficient) implementation would probably map the dependencies at construction time into a private dictionary, but this is just a quick example of how you might achieve this behavior:

public abstract class ViewModelBase : INotifyPropertyChanged
{
    [AttributeUsage(AttributeTargets.Property, AllowMultiple = true)]
    protected class DependsUponAttribute : Attribute
    {
        public string DependancyName { get; private set; }
        
        public DependsUponAttribute(string propertyName)
        {
            DependancyName = propertyName;
        }
    }

    protected virtual void RaisePropertyChanged(string propertyName)
    {
        var handlers = PropertyChanged;
        if (handlers != null)
        {
            foreach(var property in AllNotifiedProperties(propertyName))
                handlers(this, new PropertyChangedEventArgs(property));
        }
    }

    private IEnumerable<string> DependantProperties(string inputName)
    {
        return from property in GetType().GetProperties()
               where property.GetCustomAttributes(typeof(DependsUponAttribute), true).Cast<DependsUponAttribute>()
                     .Any(attribute => attribute.DependancyName == inputName)
               select property.Name;
    }

    private IEnumerable<string> NotifiedProperties(IEnumerable<string> inputs)
    {
        var dependancies = from input in inputs
                           from dependancy in DependantProperties(input)
                           select dependancy;

        return inputs.Union(dependancies).Distinct();
    }

    private IEnumerable<string> AllNotifiedProperties(string inputName)
    {
        IEnumerable<string> results = new[]{inputName};

        while (NotifiedProperties(results).Count() > results.Count())
            results = NotifiedProperties(results);

        return results;
    }

    public event PropertyChangedEventHandler PropertyChanged;
}

Adventures in MVVM – A Rails-Inspired ViewModel

Brian Genisio's House Of Bilz — Wed, 21 Oct 2009 01:22:18 GMT

More Adventures in MVVM

I have been taking a few weeks off from my personal studies/experiments in the .Net space to learn more about Ruby and Ruby on Rails (RoR). I have two main goals for this study:

Get to know another platform as an option for future development
Examine how I can incorporate different concepts into my existing framework

What follows is intended to document my experimentation with the second bullet: How might we design a ViewModel if we were in Rails? My thoughts on this are still forming, and I am still a novice in the RoR arena, so cut me some slack :).

I am pretty vocal about my thoughts on the MVVM pattern. I really like the pattern a lot and I think it solves a lot of problems that I encounter on a daily basis. Unfortunately, the implementation of the pattern – ViewModels specifically – often get overly complicated. This is why there are about a dozen major players in this arena. The plumbing necessary to create a good ViewModel is tedious and error prone. A good set of abstractions and tools make the job much easier.

The RoR approach to application development uses a lot of conventions to allow the developer to be as expressive as possible without introducing too much plumbing. The framework facilitates DRY (Don’t Repeat Yourself) so your controllers declare what they do and the magic under the hood plumbs it all together for you. How can we translate these ideas to a better implementation of the MVVM pattern? In this article, I will focus on the ViewModel portion of the MVVM pattern.

A classic ViewModel implementation

This view is simple. There is a text box bound to the Text property in the ViewModel and a button bound to the MakeLowercase command (property) in the ViewModel. The button is enabled/disabled based on the length of the Text property and clicking on the button will cause the text to go to lowercase.

<TextBox Text="{Binding Text, Mode=TwoWay, UpdateSourceTrigger=PropertyChanged}" Grid.Column="0" />
<Button Content="Make Lower" Commands:Click.Command="{Binding MakeLowercase}" Grid.Column="1" />

Next is the ViewModel in its pure (no abstractions) form:

public class MainPageViewModel : INotifyPropertyChanged
{
    public MainPageViewModel()
    {
        MakeLowercase = new DelegateCommand<pobject>(ExecuteMakeLowercase, CanExecuteMakeLowercase);
    }

    private void ExecuteMakeLowercase(object obj)
    {
        Text = Text.ToLower();
    }

    private bool CanExecuteMakeLowercase(object arg)
    {
        return !string.IsNullOrEmpty(Text);
    }

    private string _text;
    public string Text
    {
        get { return _text; }
        set
        {
            _text = value;
            FirePropertyChanged("Text");
            MakeLowercase.RaiseCanExecuteChanged();
        }
    }

    private DelegateCommand<object> _makeLowercase;
    public DelegateCommand<object> MakeLowercase
    {
        get { return _makeLowercase; }
        set
        {
            _makeLowercase = value;
            FirePropertyChanged("MakeLowercase");
        }
    }

    protected void FirePropertyChanged(string propertyName)
    {
        var handlers = PropertyChanged;
        if (handlers != null)
            handlers(this, new PropertyChangedEventArgs(propertyName));
    }

    public event PropertyChangedEventHandler PropertyChanged;
}

Problems with the traditional ViewModel implementation

Lots of plumbing (Command in the constructor, PropertyChanged in property setters, ExecuteChanged evaluation in the Text setter, etc)
Verbose properties (We can’t use auto-properties because of the need to notify of changes
Unrelated events (Text property needs to know that CanExecuteMakeLowercase needs to be re-evaluated)
INotifyPropertyChanged is error-prone due to string events
Lots of redundancies makes maintenance messy

What a Rails-Inspired ViewModel might look like

public class MainPageViewModel : ActiveViewModel<MainPageViewModel.Properties>
{
    public enum Properties { Text }

    public void Execute_MakeLowercase()
    {
        Set(Properties.Text, Get<string>(Properties.Text).ToLower());
    }

    [DependentUpon(Properties.Text)]
    public bool CanExecute_MakeLowercase()
    {
        return !string.IsNullOrEmpty(Get<string>(Properties.Text));
    }
}

My goal was to reduce the amount of plumbing and redundancies in this code to communicate only what it needs to

There is one property named Text
The MakeLowercase command will act on the Text property and make it lowercase
CanExecuteMakeLowercase will return true if Text has meaningful data
CanExecuteMakeLowercase needs to be re-evaluated with Text changes

There is a lot of magic in ActiveViewModel. I am using convention to define the properties as a list of enums (Properties). The ActiveViewModel will generate these properties dynamically. I am also using convention to create commands. Any method that is prefixed with Execute_ will be made into a command property. Any method prefixed with CanExecute_ will be evaluated in the same command. Further, the CanExecute_ method can declare the properties that will cause the commands to re-evaluate, putting the dependency where it belongs – with the method that is dependant upon it! Testability is really easy: Call the actions and validate the properties (via public Get()). I didn’t implement it, but actions based on property setters could very easily use the DependentUpon attribute to avoid INotifyPropertyChanged chaining that can get quite ugly.

Summary

I think this approach has a lot of potential. I am posting it in order to move the conversation forward. When the MVVM dust settles, and we have some best practices flushed out, what do we want our ViewModels to look like? Even though I consider this class experimental and exploratory (not meant to be used in production), I feel compelled to call out some weaknesses that will (or may) need to be addressed for a more production-ready base class:

The ActiveViewModel class will not work in Silverlight. It relies heavily on custom type descriptors which are not available in Silverlight. Hopefully, in Silverlight 4.0, we will have some better support for dynamic property generation. This may be in the form of C# 4.0 (with the DynamicObject.Try[SG]etMember overrides, for instance), property descriptors, or something else (better IronRuby support, perhaps?)
There is not a lot of type safety with the properties. They are stored internally as plain objects. The Get method lets you get at a type-casted value, but you need to know it when you ask for it. We might change the property declaration from an enum to a list of name/type pairs and enforce some better type safety in the base class?
Because there are not properties, we loose “equals semantics”. Get/Set is harder to read/follow than simply assigning and reading properties

Finally, in case you are curious, you can see my implementation (at the time of this post) of the ActiveViewModel from my Launchpad project.

Introducing DynamicWrapper

Brian Genisio's House Of Bilz — Sat, 19 Sep 2009 04:44:16 GMT

DynamicWrapper project on CodePlex

Edit: DynamicWrapper does not work in SIlverlight as I first though. My unit tests passed, but in runtime I get an exception when I try to use the class. I will be looking at some alternatives.

Over the past few weeks, I have been working on a utility that I have wanted for years: something that allows me to apply an interface to an object that matches the contract but doesn’t actually implement the interface. In other words, I’ve wanted duck typing in C#. The code and project can be found on CodePlex. It is set up so you simply copy one file into your solution and use the extension methods.

Why did I want this? Because I write a lot of unit tests and I develop in .Net with C#. Because I write way too many wrapper classes to make my code testable. For example, lets say that I have a class that I want to test and it acts upon a framework object:

public sealed class FrameworkClass
{
    internal FrameworkClass() {}
    
    public int X {get; set;}
    public int Y {get; set;}
    public int Calculate() { return DoSomeStuff(); }
}

public class MyClass
{
    public void DoSomethingWithFrameworkData(FrameworkClass value)
    {
        // Do Something
    }
}

The problem is that I can’t test MyClass because it is dependent upon FrameworkClass which I can never construct myself (it is sealed with an internal constructor and no interface). The solution for this is simple but tedious – create a wrapper class that implements an interface and proxy through the wrapper class to the real object. This approach works, but I can say this: I am sick of writing wrapper classes!

This is why I created this DynamicWrapper utility. It exposes two extension methods: realObject.As<Interface>() and wrapper.AsReal<ConcreteClass>(). It uses Reflection to emit a dynamically generated wrapper class that implements the interface, and wraps your object for you. It sounds complicated, but it is extremely simple to use.

Here is an example. Start by creating an interface that looks like the FrameworkClass:

public interface ICalculatable
{
    int X {get; set;}
    int Y {get; set;}
    int Calculate();
}

Modify your class to depend on ICalculatable:

public void DoSomethingWIthFrameworkData(ICalculatable value) {}

Now, when you pass the framework class into the MyClass, you can wrap it with the interface:

myObject.DoSomethingWithFrameworkData(frameworkObject.As<ICalculatable>());

If you need the framework object to pass back to the framework, it is really simple:

wrapper.AsReal<FrameworkClass>()

That’s all there is to it! The utility is very simple. It just gets me out of the business of writing (and maintaining) wrapper classes. I am now free to get back to real development.

*On a slightly related note, I will be focusing my learning efforts towards Ruby in the coming months.*

Adventures in MVVM – Binding Commands to ANY Event

Brian Genisio's House Of Bilz — Fri, 28 Aug 2009 01:27:12 GMT

More Adventures in MVVM

One of the biggest points of friction for me when implementing the MVVM pattern happens when I need to bind commands to events. When using Prism, I get the Button.Click command binding out of the box, but every other event needs to be wired up individually. Doing this requires a LOT of boilerplate code that is very easy to get wrong. In my last post, I published some code to alleviate that pain. Still, it requires you to write a new behavior and attachment for every event that you want to bind an event to.

For a while now, I have toyed with the idea of just binding commands to events directly. I ran into a lot of bumps in the road. For instance, every event handler has a different event argument type. This requires all of the handlers to be dynamic. I also couldn’t create an inline command binding – I will surely want to bind more than one event per control – so I need to create a collection of bindings. Creating arrays of structures created its own troubles – binding only works with FrameworkElements within the visual tree. This required me to write my own crude binding within my generic behavior.

What follows is very loosely based off of the Chinch MVVM framework. I tested this code in Silverlight and WPF and it works really well!

Assume I have a ViewModel that looks like this:

public class MainPageViewModel : INotifyPropertyChanged
{
    ...
    public ICommand MouseLeaveCommand { get; private set; }
    public ICommand MouseEnterCommand { get; private set; }
    public ICommand ClickCommand { get; private set; }
    ...
}

I can then bind the commands to events on a control (Button, for instance):

<Button Content="Click Me">
    <Behaviors:Events.Commands>
        <Behaviors:EventCommandCollection>
            <Behaviors:EventCommand CommandName="MouseEnterCommand" EventName="MouseEnter" />
            <Behaviors:EventCommand CommandName="MouseLeaveCommand" EventName="MouseLeave" />
            <Behaviors:EventCommand CommandName="ClickCommand" EventName="Click" />
        </Behaviors:EventCommandCollection>
    </Behaviors:Events.Commands>
</Button>

I no longer need to write any extra code whenever I want to attach commands to my events! There are a few caveats to this code:

The XAML requires the EventCommandCollection to be declared in the XAML. I struggled to figure out how to eliminate this but gave up. Someone smarter than me might be able to tell me what I am doing wrong.
This code does not consider command properties. Every command assumes a null parameter. If you need parameters (like data context), then you’ll have to do something differently (either use the old-school mechanism or extend this code to handle some special event types).
You don’t bind directly to the command. Instead, you declare the name of the command (Notice CommandName is not bound). The behavior binds for you using a primitive mechanism.

Here is the command behavior that does all the work:

public class Events
{
    private static readonly DependencyProperty EventBehaviorsProperty =
        DependencyProperty.RegisterAttached(
        "EventBehaviors",
        typeof(EventBehaviorCollection),
        typeof(Control),
        null);

    private static readonly DependencyProperty InternalDataContextProperty =
        DependencyProperty.RegisterAttached(
        "InternalDataContext",
        typeof(Object),
        typeof(Control),
        new PropertyMetadata(null, DataContextChanged));

    private static void DataContextChanged(DependencyObject dependencyObject, DependencyPropertyChangedEventArgs e)
    {
        var target = dependencyObject as Control;
        if (target == null) return;

        foreach (var behavior in GetOrCreateBehavior(target))
            behavior.Bind();
    }

    public static readonly DependencyProperty CommandsProperty =
        DependencyProperty.RegisterAttached(
        "Commands",
        typeof(EventCommandCollection),
        typeof(Events),
        new PropertyMetadata(null, CommandsChanged));

    public static EventCommandCollection GetCommands(DependencyObject dependencyObject)
    {
        return dependencyObject.GetValue(CommandsProperty) as EventCommandCollection;
    }

    public static void SetCommands(DependencyObject dependencyObject, EventCommandCollection eventCommands)
    {
        dependencyObject.SetValue(CommandsProperty, eventCommands);
    }

    private static void CommandsChanged(DependencyObject dependencyObject, DependencyPropertyChangedEventArgs e)
    {
        var target = dependencyObject as Control;
        if (target == null) return;

        var behaviors = GetOrCreateBehavior(target);
        foreach (var eventCommand in e.NewValue as EventCommandCollection)
        {
            var behavior = new EventBehavior(target);
            behavior.Bind(eventCommand);
            behaviors.Add(behavior);
        }

    }

    private static EventBehaviorCollection GetOrCreateBehavior(FrameworkElement target)
    {
        var behavior = target.GetValue(EventBehaviorsProperty) as EventBehaviorCollection;
        if (behavior == null)
        {
            behavior = new EventBehaviorCollection();
            target.SetValue(EventBehaviorsProperty, behavior);
            target.SetBinding(InternalDataContextProperty, new Binding());
        }

        return behavior;
    }
}

public class EventCommand
{
    public string CommandName { get; set; }
    public string EventName { get; set; }
}

public class EventCommandCollection : List<EventCommand>
{
}

public class EventBehavior : CommandBehaviorBase<Control>
{
    private EventCommand _bindingInfo;

    public EventBehavior(Control control)
        : base(control)
    {

    }

    public void Bind(EventCommand bindingInfo)
    {
        ValidateBindingInfo(bindingInfo);

        _bindingInfo = bindingInfo;

        Bind();
    }

    private void ValidateBindingInfo(EventCommand bindingInfo)
    {
        if(bindingInfo == null) throw new ArgumentException("bindingInfo");
        if (string.IsNullOrEmpty(bindingInfo.CommandName)) throw new ArgumentException("bindingInfo.CommandName");
        if (string.IsNullOrEmpty(bindingInfo.EventName)) throw new ArgumentException("bindingInfo.EventName");
    }

    public void Bind()
    {
        ValidateBindingInfo(_bindingInfo);
        HookPropertyChanged();
        HookEvent();
        SetCommand();
    }

    public void HookPropertyChanged()
    {
        var dataContext = TargetObject.DataContext as INotifyPropertyChanged;
        if (dataContext == null) return;

        dataContext.PropertyChanged -= DataContextPropertyChanged;
        dataContext.PropertyChanged += DataContextPropertyChanged;
    }

    private void DataContextPropertyChanged(object sender, PropertyChangedEventArgs e)
    {
        if (e.PropertyName == _bindingInfo.CommandName)
            SetCommand();
    }

    private void SetCommand()
    {
        var dataContext = TargetObject.DataContext;
        if (dataContext == null) return;

        var propertyInfo = dataContext.GetType().GetProperty(_bindingInfo.CommandName);
        if (propertyInfo == null) throw new ArgumentException("commandName");

        Command = propertyInfo.GetValue(dataContext, null) as ICommand;
    }

    private void HookEvent()
    {
        var eventInfo = TargetObject.GetType().GetEvent(
            _bindingInfo.EventName, BindingFlags.Public | BindingFlags.Instance);
        if (eventInfo == null) throw new ArgumentException("eventName");

        eventInfo.RemoveEventHandler(TargetObject, GetEventMethod(eventInfo));
        eventInfo.AddEventHandler(TargetObject, GetEventMethod(eventInfo));
    }

    private Delegate _method;
    private Delegate GetEventMethod(EventInfo eventInfo)
    {
        if (eventInfo == null) throw new ArgumentNullException("eventInfo");
        if (eventInfo.EventHandlerType == null) throw new ArgumentException("EventHandlerType is null");

        if (_method == null)
        {
            _method = Delegate.CreateDelegate(
                eventInfo.EventHandlerType, this,
                GetType().GetMethod("OnEventRaised",
                BindingFlags.NonPublic | BindingFlags.Instance));
        }

        return _method;
    }

    private void OnEventRaised(object sender, EventArgs e)
    {
        ExecuteCommand();
    }
}

public class EventBehaviorCollection : List<EventBehavior>
{ }