Technology | Mind-driven development

The Property Memento pattern

Edit: Find an improved implementation of the pattern here.
Edit: Find an explicit implementation of the pattern here.

This blog post shows the Property Memento as pattern for storing property values and later restoring from those. Constructive feedback is welcome everytime!

Problem description

It’s a common task in several scenarios: you want to store the value of an object’s property, then temporarily change it to perform some actions and at the end restore the original property value again. Especially with UI-related task you come into this situation quite often.

The last time I came across with this requirement is only some days/weeks ago and was a UI task as well. I created a generic detail view in WinForms, which was built up by Reflection from an object’s properties and optional metadata information. This form contained a control for the object’s values on the one side and a validation summary control for showing validation messages on the other side. The validation summary had to change its content and layout dynamically while performing validation.

Through the dynamic nature of the form unfortunately I couldn’t use the AutoSize feature and thus had to layout the control manually (calculating and setting control sizes etc.). But I still wanted to use some AutoSize functionality, at least for the validation summary. And here’s the deal: everytime the validation messages on the summary change, the control should AutoSize to fit its content. With the new size I recalculate the Height of the whole form. This task can be done by manually setting the AutoSize property temporarily. Additionally it’s necessary to temporarily set the Anchor property of the details control and the validation summary to complete the layouting process correctly.

Normally in the past I would have used a manual approach like this:

private void SomeMethod(...)
{
    int oldValSumHeight = _valSum.Height;
    int newValSumHeight = 0;

    bool oldValSumAutoSize = _valSum.AutoSize;
    AnchorStyles oldValSumAnchor = _valSum.Anchor;
    AnchorStyles oldDetailAnchor = _detailContent.Anchor;

    _valSum.AutoSize = true;
    _valSum.Anchor = AnchorStyles.Left | AnchorStyles.Top;
    _detailContent.Anchor = AnchorStyles.Left | AnchorStyles.Top;

    _valSum.SetValidationMessages(validationMessages);

    newValSumHeight = _valSum.Height;
    Height = Height - oldValSumHeight + newValSumHeight;

    _valSum.AutoSize = oldValSumAutoSize;
    _valSum.Anchor = oldValSumAnchor;
    _detailContent.Anchor = oldDetailAnchor;

    _valSum.Height = newValSumHeight;
}

What a verbose and dirty code for such a simple task! Saving the old property values, setting the new values, performing some action and restoring the original property values… It’s even hard to find out the core logic of the method. Oh dear! While this solution works, it has a really poor readability. Moreover it’s not dealing with exceptions that could occur when actions are performed in between. Thus the UI could be left in an inconsistently layouted state and presented to the user in this way. What a mess! But what’s the alternative?

The Property Memento

Better solution? What do you think about that (edit: find a better implementation here):

private void SomeMethod(...)
{
    int oldValSumHeight = _valSum.Height;
    int newValSumHeight = 0;

    using (GetAutoSizeMemento(_valSum, true))
    using (GetAnchorMemento(_valSum, AnchorStyles.Top|AnchorStyles.Left))
    using (GetAnchorMemento(_detailContent, AnchorStyles.Top|AnchorStyles.Left))
    {
        _valSum.SetValidationMessages(validationMessages);

        newValSumHeight = _valSum.Height;
        Height = Height - oldValSumHeight + newValSumHeight;
    }

    _valSum.Height = newValSumHeight;
}

private PropertyMemento<Control, bool> GetAutoSizeMemento(
    Control control, bool tempValue)
{
    return new PropertyMemento<Control, bool>(
        control, () => control.AutoSize, tempValue);
}

private PropertyMemento<Control, AnchorStyles> GetAnchorMemento(
    Control control, AnchorStyles tempValue)
{
    return new PropertyMemento<Control, AnchorStyles>(
        control, () => control.Anchor, tempValue);
}

Notice that the logic of SomeMethod() is exactly the same as in the first code snippet. But now the responsibility of storing and restoring property values is encapsulated in Memento objects which are utilized inside a using(){ } statement. GetAutoSizeMemento() and GetAnchorMemento() are just two simple helper methods to create the Memento objects, which support readability in this blog post, but nothing more…

So how is the Property Memento working conceptually? On creation of the Property Memento it stores the original value of an object’s property. Optionally it’s possible to set a new temporary value for this property as well. During the lifetime of the Property Memento the value of the property can be changed by a developer. Finally when Dispose() is called on the Property Memento, the initial property value is restored. Thus the Property Memento clearly encapsulates the task of storing and restoring property values.

The technical implementation of the Property Memento in C# uses Reflection and is shown below (edit: find a better implementation here):

public class PropertyMemento<TClass, TProperty> : IDisposable
    where TClass : class
{
    private readonly TProperty _originalPropertyValue;
    private readonly TClass _classInstance;
    private readonly Expression<Func<TProperty>> _propertySelector;

    public PropertyMemento(TClass classInstance,
        Expression<Func<TProperty>> propertySelector)
    {
        _classInstance = classInstance;
        _propertySelector = propertySelector;
        _originalPropertyValue =
            ReflectionHelper.GetPropertyValue(classInstance, propertySelector);
    }

    public PropertyMemento(TClass memberObject,
        Expression<Func<TProperty>> memberSelector, TProperty tempValue)
        : this(memberObject, memberSelector)
    {
        SetPropertyValue(tempValue);
    }

    public void Dispose()
    {
        SetPropertyValue(_originalPropertyValue);
    }

    private void SetPropertyValue(TProperty value)
    {
        ReflectionHelper.SetPropertyValue(
            _classInstance, _propertySelector, value);
    }
}

This implementation uses the following ReflectionHelper class:

static class ReflectionHelper
{
    public static PropertyInfo GetProperty<TEntity, TProperty>(
        Expression<Func<TProperty>> propertySelector)
    {
        return GetProperty<TEntity>(GetPropertyName(propertySelector));
    }

    public static PropertyInfo GetProperty<T>(string propertyName)
    {
        var propertyInfos = typeof(T).GetProperties();
        return propertyInfos.First(pi => pi.Name == propertyName);
    }

    public static string GetPropertyName<T>(
        Expression<Func<T>> propertySelector)
    {
        var memberExpression = propertySelector.Body as MemberExpression;
        return memberExpression.Member.Name;
    }

    public static TProperty GetPropertyValue<TEntity, TProperty>(
        TEntity entity, Expression<Func<TProperty>> propertySelector)
    {
        return (TProperty)GetProperty<TEntity, TProperty>(propertySelector)
            .GetValue(entity, null);
    }

    public static void SetPropertyValue<TEntity, TProperty>(TEntity entity,
        Expression<Func<TProperty>> propertySelector, TProperty value)
    {
        GetProperty<TEntity, TProperty>(propertySelector)
            .SetValue(entity, value, null);
    }
}

As you can see, the Property Memento implementation is no rocket science. The constructor gets the class instance and an Expression which selects the property from this instance. Optionally you can provide a property value that should be set temporarily in place of the original value. Getting and setting the property value is done via the ReflectionHelper class. For the sake of shortness the implementation doesn’t have a good error handling mechanism. You could employ your own checks if you want. What I like is the use of generics. This eliminates many error sources and guides a developer with the usage of the Property Memento.

Really a pattern and a Memento?

I’ve used the Property Memento now in several different situations with success and thus I think it’s justified to call it a pattern.

But is it a Memento as well? Wikipedia says about the Memento pattern:

„The memento pattern is a software design pattern that provides the ability to restore an object to its previous state […]“

And this is true for the Property Memento, where the „object“ equals a property value on a class instance! The „previous state“ is stored on creation of the Memento and „restore an object“ is done on call of Dispose().

Finally

This blog post has shown the Property Memento as pattern for storing original property values and later on restoring them.

Compared to the „manual way“ the Property Memento has valuable advantages. It encapsulates the responsibility of storing an original value and restoring it when the using() block is finished. Client code remains clean and is condensed to the core logic, while delegating responsibilities to the Property Memento by an explicit using(){ } block. Thus the code becomes much more concise and readable. Last but not least the Property Memento employs an automatic exception handling mechanism. If an exception occurs inside a using() block of the Property Memento, finally the Dispose() method is called. Thus the Property Memento restores the original property state even in exceptional situations and the user gets a consistent layouted UI.

Getting encapsulated type of Nullable

Just a short tip for today..

Sometimes I’ve had the requirement to treat value types, where I don’t know if the value type is Nullable<T> or not. Regardless of whether the value type is declared as Nullable<T> or not, it should everytime be treat as T. Thus I’ve had to find out the underlying type of the Nullable<T>.

The following extension method on Type realizes this requirement:

public static class TypeExtensions
{
    public static Type GetBareType(this Type dataType)
    {
        if (dataType != null)
        {
            if (dataType.IsGenericType &&
               (dataType.GetGenericTypeDefinition() == typeof(Nullable<>)))
            {
                dataType = Nullable.GetUnderlyingType(dataType);
            }
        }
        return dataType;
    }
}

Latch me if you can!

In my first blog post I’ve shown a common UI problem when it comes to event handling and programmatic vs. user-triggered events on the one handside and to infinite loops due to recursive event chains on the other. With event detach/attach and boolean flags I’ve shown two simple solutions which are very common in many development projects. But they have their shortcomings and just don’t feel natural. This blog post shows an alternative which I found simple and beautiful.

Latch to the rescue

Jeremy Miller introduced the Latch design pattern as possible solution for the problem at hand. It’s a tiny beautiful, yet little know solution and the latter is a pitty. A Latch encapsulates the logic of executing an action depending on the current state of the Latch. If the Latch is in „Latched“ state, no action is executed. And actions can be executed inside of the Latch (changing the state to „Latched“), preventing other actions from executing.

Latch #1: Disposing Latch

Before reading Jeremy’s post, I’ve made a sort of Latch pattern for myself. Here the Latch implements IDisposable, and the Latched state is set on creation of the Latch and reset at a call of Dispose(). This allows the application of the using() { } syntax and the Latch state is reset automatically when exceptions occur. The Latch class would look like this:

public class Latch : IDisposable
{
    public bool IsLatched { get; private set; }

    public Latch()
    {
        IsLatched = true;
    }

    public void RunIfNotLatched(Action action)
    {
        if (IsLatched)
            return;

        action();
    }

    public void Dispose()
    {
        IsLatched = false;
    }

    public static Latch Latched
    {
        get { return new Latch(); }
    }
    public static Latch UnLatched
    {
        get { return new Latch { IsLatched = false }; }
    }
}

The RunIfNotLatched() method is just a little helper which executes an action given on the current state of the Latch. The actual application of the Latch in the example code from the previous post is shown here:

public partial class SomeControl : UserControl
{
    // ...

    private Latch _textSetByCodeLatch = Latch.UnLatched;

    private ViewData _viewData;
    public ViewData ViewData
    {
        get { return _viewData; }
        set
        {
            _viewData = value;
            if (value != null)
            {
                using (_textSetByCodeLatch = new Latch())
                {
                    _someTextBox.Text = value.SomeValue;
                }
                // other operations
            }
        }
    }

    private void OnSomeTextBoxTextChanged(object sender, EventArgs e)
    {
        _textSetByCodeLatch.RunIfNotLatched(() =>
        {
            // perform data/view update operations
        });
    }
}

At first sight I liked the using() { } syntax. It frees the application code from manually reseting the Latch to UnLatched state. At second sight I think there could be a cleaner solution. In my Latch implementation the using() { } syntax is kind of misused and could lead to irritations because there is implicit knowledge about the internal functionality of the Latch. Again, the intent is not explicitly revealed.

Latch #2: Boolean Latch

A cleaner solution with explicit methods for running actions inside of the Latch and missing action execution when other actions have entered the Latch could be the following Latch implementation:

public class Latch
{
    public bool IsLatched { get; private set; }

    public void RunLatched(Action action)
    {
        try
        {
            IsLatched = true;
            action();
        }
        finally
        {
            IsLatched = false;
        }
    }

    public void RunIfNotLatched(Action action)
    {
        if (IsLatched)
            return;

        action();
    }
}

Here the basic boolean logic behind matches with the Disposing Latch, but the syntax has changed. The Latch now contains two methods. RunLatched() executes an action inside the Latch and prevents actions from being executed in RunIfNotLatched(). Here’s the usage for this Latch type in our example:

public partial class SomeControl : UserControl
{
    // ...

    private readonly Latch _textSetByCodeLatch = new Latch();

    private ViewData _viewData;
    public ViewData ViewData
    {
        get { return _viewData; }
        set
        {
            _viewData = value;
            if (value != null)
            {
                _textSetByCodeLatch.RunLatched(() =>
                {
                    _someTextBox.Text = value.SomeValue;
                });
                // other operations
            }
        }
    }

    private void OnSomeTextBoxTextChanged(object sender, EventArgs e)
    {
        _textSetByCodeLatch.RunIfNotLatched(() =>
        {
            // perform data/view update operations
        });
    }
}

Now the Latch has a cleaner and more explicit syntax. And like the Disposing Latch it has a clean exception handling mechanism. That’s the good news. With that our Boolean Latch is applicable in most simple scenarios. But not in all! Imagine parallel execution of UI actions. Moreover imagine having two actions which should be run in RunLatched() of the same Latch object – again in parallel:

Action 1 enters RunLatched() and the Latch changes its state.
Action 2 enters RunLatched(), the Latch state remains in IsLatched.
Action 1 leaves RunLatched() and the Latch changes its state to not latched.

Step 3 is the problem. Action 2 is still running inside the Latch, but due to the boolean logic the Latch is not latched any longer. Thus other actions are executed when given to RunIfNotLatched(), which is no help on the initial problem. This is not only true for the Boolean Latch, but for the Disposing Latch as well.

Latch #3: Counting Latch

This problem is solved by the Counting Latch, which is most similar to Jeremy’s Latch implementation. Instead of having just a boolean discriminator, it employs a counter for parallel RunLatched() calls. The IsLatched state is determined based on this counter. If it’s equal to 0, the Latch is not latched (because no method is currently running inside of RunLatched()). Else the Latch is treat as latched. Here’s the implementation of this Latch variant (edit: thanks nwiersma for the thread-safe hint):

public class Latch
{
    private readonly object _counterLock = new object();

    public int LatchCounter { get; private set; }

    public bool IsLatched
    {
        get { return (LatchCounter > 0); }
    }

    public void RunLatched(Action action)
    {
        try
        {
            lock(_counterLock) { LatchCounter++; }
            action();
        }
        finally
        {
            lock(_counterLock) { LatchCounter--; }
        }
    }

    public void RunIfNotLatched(Action action)
    {
        if (IsLatched)
            return;

        action();
    }
}

The usage in this case is equivalent to the Boolean Latch. You should note that each of these Latch implementations works, it’s just a matter of your requirements which of them you want to use. The Counting Latch as most generic Latch implementation above and applies to most situations.

Benefits of using the Latch

Using the Latch for the foresaid problems has clear advantages over the use of event detach/attach and boolean flags. First the Latch encapsulates the logic of running actions depending on a state, in this case the current execution of another action. Thus the purpose of a Latch is explicit, in contrast to the implicit intent of e.g. boolean flags. This increases code readability.

The second advantage comes with resetting the initial state. The Latch performs this task itself when an action leaves the RunLatched() method for example. With boolean flags and event detach/attach this is your task. It’s most likely getting problematic if exceptions are thrown inside an action. The Latch takes over the responsibility of automatically rolling back the state of the Latch on occurrence of an exception.

In conclusion the Latch is a pretty simple design pattern which increases readability and feels right for the problem of dependent action execution. For myself, at least I’ve found some nice solution for UI event reaction depending on the source of the trigger of the event and for infinite event loops, without relying on ugly boolean flags or event attach/detach.

A common UI problem

This blog post is all about a common UI-related programming problem. Ever since my first UI-based application I’ve come across with this problem and never found a satisfying way to resolve it (until now 😉 ). This first blog post is about describing the problem and my former solution approaches. In the next blog post I will demonstrate a more proper solution.

The code in these two blog posts is using WinForms and C#, but it should be easy adoptable to other UI technologies as well.

Problem description

It’s a common problem: you want to react on an event like the TextChanged event on a TextBox, but ONLY if the user changed the text and it’s not changed programmatically. For example you want to update some data, when the user changes the content of a TextBox, but this update process should not be triggered when the progam itself sets some data and therefore updates the text. The starting point for that could be something like the following code:

public partial class SomeControl : UserControl
{
    // ...

    private ViewData _viewData;
    public ViewData ViewData
    {
        get { return _viewData; }
        set
        {
            _viewData = value;
            if (value != null)
            {
                _someTextBox.Text = value.SomeValue;
                // other operations
            }
        }
    }

    private void OnSomeTextBoxTextChanged(object sender, EventArgs e)
    {
        // perform data/view update operations
    }
}

Here the OnSomeTextBoxTextChanged() method is bound to the _someTextBox.TextChanged event. ViewData is a class with arbitrary data that should show up in the UI.
Notice the problem: when the ViewData property is set programmatically the OnSomeTextBoxTextChanged() method is being executed, which is not what was intended (firing the event only when the user changes the value of the TextBox).

A similar problem arises with infinite loops. Imagine a user changes something in the UI and an event X is fired. You hook this event and start a complex UI workflow, which at the end fires the event X again. The proces is executed again and very easy you come into an infinite loop situation. If you are an UI developer you would very probably agree that UI event chains are often opaque and can get messy.

Let’s look at some obvious, however not very elegant, solutions.

Approach #1: Temporary event detach

One of those simple solution is the temporary detachment of the problematic event. For example if you don’t want to react on the TextChanged event when the TextBox.Text property is set programmatically, you could detach your event handler from TextChanged before setting the Text and afterwards attach it again. This approach is shown in the following example code:

public partial class SomeControl : UserControl
{
    // ...

    private ViewData _viewData;
    public ViewData ViewData
    {
        get { return _viewData; }
        set
        {
            _viewData = value;
            if (value != null)
            {
                _someTextBox.TextChanged -= OnSomeTextBoxTextChanged;
                _someTextBox.Text = value.SomeValue;
                _someTextBox.TextChanged += OnSomeTextBoxTextChanged;

                // other operations
            }
        }
    }

    private void OnSomeTextBoxTextChanged(object sender, EventArgs e)
    {
        // perform data/view update operations
    }
}

While this is working, it’s not a recommendable solution, because there are several shortcomings. First the manual event handling is not very intuitive and doesn’t explicitly reveal the intent of the programmer with this manual process. Thus your code is more difficult to read for others (and after some months for you as well). Moreover, you get undefined states when exceptions are thrown and caught in an outer component (and you miss a finally which attaches the event again). Then the event handler could be detached further on and the UI isn’t working properly afterwards. The whole event detach/attach process is getting very messy if you have complex views with many such problematic events. Last but not least this manual event handling process binds your code tightly to the view and you get trouble if you want to refactor several parts out.

Approach #2: Boolean flags

A similarly simple approach comes with boolean flags which indicate that a value is currently set programmatically and thus that Changed events should not be handled. The following code shows an example how this could solve our initial problem:

public partial class SomeControl : UserControl
{
    // ...

    private bool _isTextSetByProgram = false;

    private ViewData _viewData;
    public ViewData ViewData
    {
        get { return _viewData; }
        set
        {
            _viewData = value;
            if (value != null)
            {
                _isTextSetByProgram = true;
                _someTextBox.Text = value.SomeValue;
                _isTextSetByProgram = false;

                // other operations
            }
        }
    }

    private void OnSomeTextBoxTextChanged(object sender, EventArgs e)
    {
        if (!_isTextSetByProgram)
        {
            // perform data/view update operations
        }
    }
}

I think this is the most common solution that I’ve seen for the problem. For myself I must admit that I’ve mostly used this approach. But it has the same disadvantages like the event detach/attach solution (except the tight view coupling). Boolean variables don’t explicitly show the intent behind them and get likewise messy if used in complex situations where you could have dozens of those variables scattered around a view.

So while those solutions are very widespread and work they just don’t feel right and clean. But what’s the alternative? An interesting little one I will show you in the next post which comes shortly.

Some thoughts on Event-Based Components

The German software engineer Ralf Westphal currently spreads some knowledge about an alternative model for programming components and especially communication between them. Due to their nature they are called Event-Based Components. After some discussion with colleagues at SDX I want to share some of my thoughts on that with you (of course for further discussion as well).
The aim of Event-Based Components (EBC) is to create software components that are really composable without specific topological dependencies. You can compare EBCs with elements in electronic circuits. But first things first…

Interface-Based Components style

Normally we’re developing components in .NET as IBCs: Interface-Based Components. That means client classes have topological and functional dependencies to interfaces (or directly to other classes), which provide some sort of functionality. Well developed, such a dependency could be resolved with a Dependency Injection container like StructureMap:

class Program
{
    static void Main(string[] args)
    {
        // Bind (here: StructureMap)
        ObjectFactory.Initialize(x =>
        {
            x.For<IBusinessClient>().Use<BusinessClient>();
            x.For<IDataAccessComponent>().Use<DataAccessComponent>();
        });

        // Resolve and Run
        IBusinessClient client = ObjectFactory.GetInstance<IBusinessClient>();
        client.BusinessOperation(0);
    }
}

interface IBusinessClient
{
    void BusinessOperation(int personId);
}

class BusinessClient : IBusinessClient
{
    private readonly IDataAccessComponent _dataAccessComponent;

    public BusinessClient(IDataAccessComponent dataAccessComponent)
    {
        _dataAccessComponent = dataAccessComponent;
    }

    public void BusinessOperation(int personId)
    {
        Person p = _dataAccessComponent.GetPerson(personId);
        // do something ...
    }
}

interface IDataAccessComponent
{
    Person GetPerson(int id);
}

class DataAccessComponent : IDataAccessComponent
{
    public Person GetPerson(int id)
    {
        return  // ...some person...
    }
}

That’s pretty standard so far, isn’t it? In Ralf’s opinion this programming style lacks real composability of the components. Due to the topological dependency the clients is bound to a specific interface and no arbitrary component can perform the functionality. Instead a component has to implement the specific interface. You’re not able to use components which could provide the functionality, but don’t implement the interface…

Event-Based Components style

Ralf suggests Event-Based Components to the rescue. Components in this programming style can be compared to components in electronic circuits. Methods act as input pins of a component and can be called by other components. Events/delegates act as output pins and establish a connection to other components that should be used by the component or to provide calculation results. The output pins can be bound to any arbitrary method that meet the signature. Thus the dependency is still functional, but not topological any more.
The example above in EBC style could look as follows:

class Program
{
    static void Main(string[] args)
    {
        // Build
        var client = new BusinessClient();
        var dataAccess = new DataAccessComponent();

        // Bind
        client.GetPerson = dataAccess.GetPerson;

        // Run
        client.BusinessOperation(0);
    }
}

class BusinessClient
{
    public Func<int, Person> GetPerson { get; set; }

    public void BusinessOperation(int personId)
    {
        Person p = GetPerson(personId);
        // do something ...
    }
}

class DataAccessComponent
{
    public Person GetPerson(int id)
    {
        return  // ... some person ...
    }
}

This example shows the components BusinessClient and DataAccessComponent interacting as EBCs in a very simple form by using the Func<T> delegate type and thus enabling symmetric communication. Ralf encourages the use of standard input/output pins as Action<object>, which leads to asymmetric communication, because the DataAccessComponent would need to declare an output pin for providing the Person as result of GetPerson(). For the sake of simplicity I haven’t followed this principle here.

So the example uses a Func<T> delegate and no event. But you can still think of it as Event-Based Component, just because events are nothing more than multicast delegates. I could have used events instead of the simple delegate as well, but I’m quite fine, because I don’t need the functionality of multiple subscribers here.

As you can see from the example, just like IBCs the EBCs have some kind of initial Bootstrapper phase. This is the time when the components are composed. The output pins of a component’s client (BusinessClient in this example) are connected with the input pins of the component itself (here: DataAccessComponent).

Benefits

When I first saw EBCs I thought: „Dude, this is damn cool, isn’t it?“. Indeed this kind of programming style first feels strange and alternate and thus for me it’s really interesting. But are there some real benefits as well?

I think one big benefit of EBCs is their composability. A client hasn’t to know the interface of a component from which he wants to use some functionality. A component on the other side is not forced to implement an interface to provide some functionality, but it’s still retaining loose coupling. Even without interfaces the components are still independent from each other and have great testability.

Other benefits I see are the exchangeability and the topological independence. Components are not bound to a specific topological context in form of interfaces and thus are independent from topological changes on the interfaces. You can exchange the components easily by replacing the binding section with any other setup phase and can binding other methods to them. Especially your components are not forced to use (or implement) some kind of interface from which they will perhaps use just one single functionality…

Last but not least I see a very easy way to intercept calls and adding functionality without changing the components themselves. If you use events as output pins you can add some more event handlers in the binding phase. Thus you can easily integrate Logging, Tracing etc. into your applications. Of course you can achieve this with IBCs as well, I just say that EBCs are suiting very well for those requirements.

Drawbacks

Besides those benefits in my opinion there are some significant drawbacks as well.

First of all is the additional complexity which comes with EBCs. Composing EBCs can become complex, at least in projects of significant size. Due to binding methods and events together on the fine instead of interfaces on the coarse, there have to be much more binding statements. In fact you can think of an event’s signature as a one-method interface that has to be fulfilled from components. Furthermore (again especially in projects of a reasonable size) you will loose intelligibility and overview over your system and the component interaction. Any arbitrary component can provide a functionality and there is no way to navigate between layers and components as clients and suppliers of functionality. Explicit interfaces are much more comprehensive than such „implicit“ specifications. Perhaps in the future there will be tools that simplify composition between EBCs and navigation through EBCs, but until there’s such a tool I consider this as serious drawback.

Another drawback of EBCs is the loss of interfaces as formal contract of coherent functionality. Of course you can define interfaces and let your components implement them, but while clients are not compelled to use them they loose much of their value. Interfaces force components to implement a certain set of functionality completely and make this set explicit. Clients have to refer this contract explicitly. Explicit contracts lead to intention revealing and this is a good thing!

Conclusion

So in my opinion EBCs have benefits as well as shortcomings. I think they are worth investigating and knowing them, but at the moment I don’t see that they will establish well and become a replacement for IBCs. First there is the higher complexity, which could perhaps be solved by tools and some sort of „DI container“ for EBCs in the future. But second, being explicit and define formal contracts through explicit interfaces is no bad thing. Of course it’s not cheap as well, but I don’t see that this justifies the application of EBCs on the small scale. On the big scale there are other solutions like BizTalk, NServiceBus etc. to achieve the goal of pluggable components which have features like scalability as well. So perhaps there are delimited scenarios for using EBCs (like component topologies that change often), but I would not suggest to use them in general.

Thanks Microsoft!

Hey guys. Wow, one month has elapsed without any blog post here. Sorry for that… At the moment I’m really busy with some private, but also technical/conceptual topics. So here comes just a short sign of life 🙂 But stay tuned for more blog posts in some weeks…

Today I was really surprised when FedEx delivered a package from Microsoft (by air freight) to me. Inside was a Visual Studio 2010 surprise gift: A laser-engraved cube from the VS2010/.NET4-team with a nice statement from Soma. He and Microsoft say „Thank you“ (me), so it’s time for me to say: Thank you for that surprise as well!

I don’t exactly know why I got this present but I think it’s because of my engagement and direct contact to the Code Contracts team in 2009. Thanks guys! I hope to see this technology improving further and becoming a first-level feature of Visual Studio (the tools!), .NET and perhaps C# as well. And I hope to give more support to evolving Microsoft technologies. There are some inspiring movements and a lot of innovation at the moment, which are really encouraging me.

Code Contracts Survey

Some days ago I took deeper insights into Code Contracts, which are included in .NET 4.0.
Microsoft currently takes a survey on Code Contracts and the Code Contracts tools. Give them feedback to support improvement of Code Contracts.

You can find the survey here: http://codecontracts.questionpro.com

ASP.NET MVC Quick Tip: Check Data Annotations from code

During the last weeks I got some insights on ASP.NET MVC 2. Personally I like the programming model of MVC in contrast to WebForms, although the productivity first seems to be lower in common data-driven scenarios. One of the most advertised features of MVC 2 is the support of Data Annotations for adding validators and further information right to your model via attributes. Data Annotations have their origins in ASP.NET Dynamic Data and are defined in the System.ComponentModel.DataAnnotations namespace that ships with .NET 4.0. Microsoft is promoting Data Annotations even further and beside MVC and Dynamic Data they can be used in Silverlight, too.

Data Annotations offer many capabilities for model validation to your application. There are predefined validators for common constraints: RangeAttribute, RegularExpressionAttribute, RequiredAttribute and StringLengthAttribute. Those attributes can be automatically checked on the client-side (via Javascript) as well. Furthermore there is a CustomValidationAttribute which allows you to define custom validation logic. Personally I feel a bit ambivalent on Data Annotations. Beside of validation logic you are able to define UI-relevant information on your model which I can’t encourage if done on the core domain model. On the other side you are able to extend your model with Data Annotations on the UI layer… But I don’t want to discuss the usage of Data Annotations here. There are scenarios where they are a perfect match and there are other cases where you want to do validation on your own…

Simple example

If you use Data Annotations for validation you get great tool support in ASP.NET MVC 2 and other UI technologies. Imagine the following model class Product:

public class Product
{
    [Required(ErrorMessage="ProductID is a required field")]
    public int ProductID { get; set; }

    [Required(ErrorMessage = "ProductName is a required field")]
    [StringLength(40, ErrorMessage = "ProductName can only contain up to 40 characters")]
    public string ProductName { get; set; }

    [StringLength(20, ErrorMessage = "QuantityPerUnit can only contain up to 20 characters")]
    public string QuantityPerUnit { get; set; }

    [Range(0, (double)decimal.MaxValue, ErrorMessage = "UnitPrice must be a valid positive currency")]
    public decimal? UnitPrice { get; set; }
}

Entities of this model class should be editable through the following strongly-typed view Edit.aspx:

<%@ Page Title="Edit Product" Language="C#"  Inherits="System.Web.Mvc.ViewPage<Product>" %>

<h2>Edit Product</h2>

<% using (Html.BeginForm()) {%>
<%: Html.ValidationSummary(true) %>

<fieldset style="padding:10px;">
<legend>Product Fields model.ProductName) %>
</div>
<div class="editor-field">
    <%: Html.TextBoxFor(model => model.ProductName) %>
    <%: Html.ValidationMessageFor(model => model.ProductName) %>
</div>

<div class="editor-label" style="margin-top:10px;">
    <%: Html.LabelFor(model => model.QuantityPerUnit) %>
</div>
<div class="editor-field">
    <%: Html.TextBoxFor(model => model.QuantityPerUnit) %>
    <%: Html.ValidationMessageFor(model => model.QuantityPerUnit) %>
</div>

<div class="editor-label" style="margin-top:10px;">
    <%: Html.LabelFor(model => model.UnitPrice) %>
</div>
<div class="editor-field">
    <%: Html.TextBoxFor(model => model.UnitPrice, String.Format("{0:F}", Model.UnitPrice)) %>
    <%: Html.ValidationMessageFor(model => model.UnitPrice) %>
</div>

<p style="margin-top:10px;">
    <input type="submit" value="Save" />
</p>
</fieldset>
<% } %>

When posting the form in this view the following action Edit() on the ProductController is invoked:

[HttpPost]
public ActionResult Edit(Products product)
{
    if (!ModelState.IsValid)
        return View(product);

    // ...
}

And here’s where magic comes into play. When posting the form the Data Annotations on the Product class are checked automatically. If there are any validation errors ModelState.IsValid is set to false and ModelState itself will contain the error messages. Those error messages automatically are displayed in the UI through the Html.ValidationMessageFor() helpers as shown below:
ASP.NET MVC 2 - Validation with Data Annotations

Everything’s fine?

Now you could think that everything’s fine with this solution, right? But that’s not the case! Data Annotations have an important and not very obvious shortcoming which can lead to serious data consistency problems. The problem: Data Annotations are checked during the model binding phase based on the posted form values and not on the bound model entity. That means only the Data Annotations on the posted form values are checked, but not other properties which are perhaps defined on the model class, but missing in the form values. Imagine for example some bad guy who visits your page and edits a Product. Before posting the form he manipulates the DOM of the page and removes some form values. Those values will not be checked on server-side and thus the (invalid) Product will be saved to the DB or some operations will be done on it. Got the point?

So what can we do? We can manually check the defined validation Data Annotations in our controller action on the model class after the model binding procedure. Therefore we can for example develop a custom action filter attribute (inspired from here):

public class ModelValidationAttribute : ActionFilterAttribute
{
    public override void OnActionExecuting(ActionExecutingContext filterContext)
    {
        // get the controller for access to the ModelState dictionary
        var controller = filterContext.Controller as Controller;
        if(controller != null)
        {
            var modelState = controller.ModelState;

            // get entities that could have validation attributes
            foreach (var entity in filterContext.ActionParameters.Values.Where(o => o != null))
            {
                // get metadata attribute
                MetadataTypeAttribute metadataTypeAttribute =
                    entity.GetType().GetCustomAttributes(typeof(MetadataTypeAttribute), true)
                        .FirstOrDefault() as MetadataTypeAttribute;

                Type attributedType = (metadataTypeAttribute != null)
                    ? metadataTypeAttribute.MetadataClassType
                    : entity.GetType();

                // get all properties of entity class and possibly defined metadata class
                var attributedTypeProperties = TypeDescriptor.GetProperties(attributedType)
                    .Cast<PropertyDescriptor>();
                var entityProperties = TypeDescriptor.GetProperties(entity.GetType())
                    .Cast<PropertyDescriptor>();

                // get errors from all validation attributes of entity and metadata class
                var errors = from attributedTypeProperty in attributedTypeProperties
                             join entityProperty in entityProperties
                             on attributedTypeProperty.Name equals entityProperty.Name
                             from attribute in attributedTypeProperty.Attributes.OfType<ValidationAttribute>()
                             where !attribute.IsValid(entityProperty.GetValue(entity))
                             select new KeyValuePair<string, string>(attributedTypeProperty.Name,
                                 attribute.FormatErrorMessage(string.Empty));

                // add errors to ModelState dictionary
                foreach (var error in errors)
                    if (!modelState.ContainsKey(error.Key))
                        modelState.AddModelError(error.Key, error.Value);
            }
        }

        base.OnActionExecuting(filterContext);
    }
}

This attribute takes all validation attributes into account which are defined on the model class itself or on an associated metadata class. The attribute adds all validation errors to the ModelState dictionary of the controller which have not been added before and which are defined in the ErrorMessage or the Error Resource of the validation attribute. Note that your controller has to derive from the Controller class and not from ControllerBase, but that’s the default setting and should not be a problem.

Now we only have to add this attribute to our controller action and validation will be done on the bound model class:

[HttpPost]
[ModelValidation]
public ActionResult EditProduct(Products product)
{
    if (!ModelState.IsValid)
        return View(product);

    // ...
}

Conclusion

This post has shown how you can check defined validation Data Annotations from your code and why it’s important in ASP.NET MVC 2 to do so. Of course you don’t have to define a custom action filter attribute for this task and can do this task by a custom validation helper in your business logic if you like. Once again this story told me one thing: don’t rely on technical solutions and question their background behavior all the time…

MIX10: And where was Live Mesh?

Some weeks ago there was MIX10 in Vegas with several interesting topics. I was inspired by the Windows Phone 7 developer experience with Silverlight and OData as open protocol for delivering collections of data as feed in the browser. There were other great sessions as well, but I missed one big thing: Live Mesh and the former Live Framework (R.I.P.) as developer portion of it.

It has been very quiet around Live Mesh (a.k.a. Windows Live Devices) in the last months. Celebrated as rock star on PDC08 and honored with several awards Live Mesh is one beautiful example of how Microsoft is unable to place great products with huge potential on the market. News on it are missing for quite a while now and developers are confused by the sudden death of the Live Framework. At this time one fact remains: Live Mesh will be part of the Windows Live Wave 4 as Windows Live Devices, but that’s it. After getting no real news on the PDC09 regarding Live Mesh and the Live Framework many people thought the MIX10 would set the stage for the new Windows Live Wave 4. I know 3 sources of people at Microsoft who were pointing to MIX10 as well when speaking about Live Mesh and the Live Framework. But their signs were wrong and again developers get disappointed. MIX10 brought not one session or info about Live Wave 4 / Live Mesh / Live Framework and that’s a shame.

I don’t know what Microsoft is planning. I don’t know when news on the Live stuff will be published. I don’t know why there are no updates on this hot topic. I don’t know where this will end. But I know and believe that Microsoft wastes the huge potential of a great developer and end user platform which could have been used as central environment of data, apps and people surrounding all devices. The bits that have been published with the Live Framework CTP on PDC08 were great and fun to use, but they have been cut off. I just can repeat it: Microsoft is really good in wasting potential…

A look at: Contract Driven Development

Today I want to take a look at this paper (PDF) entitled „Contract Driven Development = Test Driven Development – Writing Test Cases„. Like the paper on SDD I found this essay on my research for a synergetic development approach that takes both DbC and TDD into account.

The paper was written by A. Leitner et al. at the ETH Zurich in 2007, when important steps towards automatic testing had been already made. One of the co-authors of the paper is Bertrand Meyer, the inventor of the Eiffel programming language which can be seen as cradle of DbC. Hence it’s not surprising that the paper and the described tool are based on Eiffel.

Content of the paper

The paper describes Contract Driven Development (CDD) as new approach to lower the effort for writing tests with intensive use of contracts. This approach is based on a mechanism to extract test cases completely automatically from failure-producing runs of a component, where contracts act as test oracle.

In the introduction the paper takes a short look at current developments towards automatic testing and shows the drawbacks that come with many tools. Automatic testing tools don’t know the semantics of a program and the insights a programmer has and thus those tools cannot distinguish between meaningful and meaningless inputs. CDD wants to overcome this drawback. It relies on the observation that developers are often writing implicit test cases when manually running a program to determine the correct behavior of their code. But many developers don’t extract those test cases as automatic unit tests and thus those tests cannot be run in a reproducible way.

The paper presents CDD as method that captures those implicit test cases automatically and extracts them into explicit tests. One important limitation is that it only captures test cases which produce a failure e.g. through a broken contract or other exceptions. With this approach the resulting test suite contains tests for mistakes made by the developers in the past. The developer builds up this test suite by running the application with corresponding input values. The authors state that the test suite would have similar properties to a suite as result from TDD when you write contracts before the implementation of a feature. You can find my personal thoughts on this below.

The paper describes a mechanism by which CDD observes program executions and detects the last uninfected state when a failure occurs. In this case CDD takes a snapshot of this state and a new test case for the failing component is created automatically. The snapshot serves as starting context for the test case by which the failure can be reproduced.

With this process the developer has to provide the inputs triggering a failure only once. Then CDD jumps in, saves the values that lead to the failure and extracts a test case to reproduce the failure. The developer can go forward with his implementation and can choose to fix the bug later on while the failure is saved as reproducible test case. Contracts can help a lot in this process since they can act as oracle for expected behavior and can express assertions that go beyond some technical exceptions. With this the benefit of CDD is mainly driven by a extensive utilization of contracts.

The authors finish with a conclusion of their work:

This article explains the fundamentals of the Contract Driven Development approach. A tool autonomously observes the developer while he is working on a program and extracts test cases from failures either provoked by the developer (in the spirit of test driven development) or by mistake (leading to a regression test). The approach is novel in that complete test cases are extracted not only from the information provided by the system under test, but also from non-permanent clues given by the programmer during development.

My thoughts

Personally I feel a little ambivalent about the CDD approach. First I like the idea of making implicit test cases which are run by the developer explicit by extracting them automatically. This includes the developer’s knowledge about the context of an application into the generated test cases and thus goes beyond the technical aspect of automatic testing. It takes some work on writing test cases from the developer’s shoulder, but it doesn’t have as many advantages as one may think…

Expected functional behavior can be defined by contracts (postconditions, invariants) which act as test oracle for CDD. But it’s a limitation as well. Important characteristics of code are difficult to define with contracts while they can be easily defined with explicit unit tests (aspect of expressiveness). Thus CDD is limited in its expressiveness as well.

Furthermore CDD extracts tests for failing runs only. But what about the other side of the medal? For successful runs no test case will be generated automatically which leads to the problem that if anything in the code changes there is no possibility to check the successful tests without running them manually again. Thus CDD is not suitable for complete regression testing.

Last but not least the authors state that a test suite created with CDD is very similar to TDD (beside other parallels to TDD). Moreover the title of the paper gets it to the simple formula „CDD = TDD – Writing Test Cases“. Here I strongly disagree! CDD and TDD have very different properties. TDD takes things like code design and specification into account, is well-suited for documentation purposes and creates a real regression testing suite. None of those aspects is in scope of CDD, so TDD goes far beyond CDD.

At the end I think CDD is an interesting approach, but the benefits are bought dearly and eaten up by the drawbacks. One of the most serious drawbacks for me (personally) is the design aspect. If you rely on CDD you are not driving your API design to be clear and lucid. There will be no unit tests for which you want to have loosely coupled components and furthermore CDD will everytime run hard against your concrete infrastructure.
To make a final advice: The only scenario where I would use CDD is for automatic test generation when running the software in production. If something fails in production with CDD you as developer could get immediate feedback about what went wrong and you could immediately reproduce the failure by running the extracted test case. This would be a nice support for bugfixing and it would be really valuable. But for testing purposes in the development process I don’t see a chance for CDD.