The last nuget release was already done without any involvement from myself. I’m doing my best to help them getting up to speed with the internals, but I’ve high confidence that they won’t need much help to really grok it.

Thank you all for your support!

As technology is the battlefield of opinionated minds, not every feedback I received was pleasant (especially from the Belgian “what’s wrong with good old unit test” brigade), but overall I’m very pleased with the perception and the feedback for the framework.

As you may have noticed, I recently made a big technology switch. Since the start of the year I spend most of the time working with Ruby on Rails on OSX. Originally I thought Mono would give me a great opportunity to continue using Machine.Fakes, but as it turns out I currently just don’t have the time to do that. Maintaining a tool/framework without actually using it on a daily basis feels just wrong. In retrospective I think I must have anticipated something like this last year, when Alexander Gross and I moved Machine.Fakes into the Machine organization on Github.

The worst future for Machine.Fakes I can imagine, is that it becomes just another abandoned .NET open source framework, like all the dead ones on Codeplex. So this is my call for help:

If you’re using Machine.Fakes and are willing to take over as the active maintainer, please drop me a line. I will assist you as good as I can in order to make this happen!

Today is probably going to be a very personal post and for that matter also non-technical one.

So, what happened in those 512 days?

First of all, 512 days ago I deliberately stopped blogging. I had lost all fun in writing. It felt more than a burden than anything useful to me. Well I guess that had something to do with a slowly and painful kind of burnout I experienced during my time at a large German consultancy. It took me a while to realize what’s going on with me, but in the end, I think, I made the right decision leaving the contracting, ups sorry, I mean consulting business.

I’ve spend a lot of my free time in the last 2 years doing some form of community work. Not via blogging, but rather by

• Building Machine.Fakes,
• speaking at several conferences, user groups and open spaces,
• facilitating the F# bookclub in Munich 2010 where we worked through Real-World Functional Programming,
• and helping Albert Weinert to get the .NET Online User Group off the ground.

Besides I helped sucesfully delivering 3 large projects in the time. Two of them exceeded the customers expectations. One didn’t. Simply put, I will never do any form of TFS customization again, never ever.

In mid 2010, out of curiosity, I bought my first Apple computer, a MacBook Pro. I started to play around with it and actually liked it a lot. Guess what, I’m an IPhone and IPod owner, too. I’m not religious about Apple products, though. They work for me and excactly deliver what I expect and need from those devices.

Well, and after a while of using OSX, I began revisiting Ruby (after my initial steps in 2008) and picked up where I left the last time. I learned the basics of using VIM, Git and started to play around with Ruby on Rails and with Rails the whole topic of web development (after having left the topic in 2003).

Big changes are coming for me in 2012

As you might have noticed, I’ve revived my blog. The design and the technology chosen might give you an idea where this is all heading.

Next year I’m going to work in a new team, with non .NET technology, with a unix based OS as my primary development environment. I’m really exited to join XING as a developer working on their Ruby on Rails based platform.

Besides I’m planning to learn a new (non .NET) programming language next year, that currently feels completely alien to me, namely Clojure. If everything goes as planned we’re going to re-use the bookclub format we used in 2010 for the F# bookclub in Munich, though in a somewhat virtualized form, and try to get into the Joy of Clojure.

Last but not least, I’m not nuts and discard everything I learned during the last years.

I’m probably going to play with MonoDevelop and try to learn how to build iOS, Android and Cocoa apps using Mono. At least that’s the plan.

On leaving .NET

What does leaving acutally mean? Let’s break this down a bit:

• Am I going to stop playing the active role for Machine.Fakes? Undecided, but probable since I won’t be using it on a day to day basis next year. I’ve ideas for re-using it under Mono, but I haven’t actually tried so far. We’ll see …

• Do I stop being in touch with parts of the .NET community? Don’t be silly

• Do I stop visiting .NET Open Spaces or UserGroups Well, that is at least not my plan.

What, no leaving .NET rant?

In the last 4 years of active community involvement I had the honour and pleasure to get to know a great bunch of .NET developers. Talented and gifted people, from all over Germany (and even outside Germany), each of them awesome in his own way.

Just to name a few @agross, @sforkmann, @ilkerde, @StefanLieser, @mikebild, @sshishkin, @lanwin, @cdeger, @oakinger, @jpboodhoo, @kostjaklein, @torstenweber, @gregyoung and a lot more. I could probably make the list a lot longer, but those are the people that managed to leave a lasting impact on me. Thank you all!

The German .NET community has changed tremendously (for the good) in the time I’ve been working with .NET, which is in great parts a result of the work of those people. Moving away from focus solely on tools crafted by you know who, to embrace and teach practices/principles of of professional software development, like SOLID, TDD/BDD/ATDD, Continuous Integration, Continuous Delivery, et al.

Microsoft (at least in my opinion) has also changed a lot (well at least in some areas, thank you ASP.NET team!). They’re hosting code at publicly available locations, they’re accepting patches from the outside and they actually listen carefully to community feedback. They still got a lot to improve, but hey, I wouldn’t believed you if you’d told me 4 years ago how parts of MS engage with the community today.

Why a technology change?

Change often implies frustration or dissatisfaction with something. I want this to be as clear as possible: Those are not my primary reasons.

I’m going to tell you a little secret right now, well sort of. Some of my older colleagues know this, some still don’t:

I never owned a computer before my 21st birthday. I didn’t even write a program till I was 22.

Let that sink in for a moment. Nevertheless, I somehow managed to leave every company I’ve worked for in the the last 10 years with the impression that I was one of the top software developers they ever worked with.

I often wondered how I managed to pull that off, but I guess it boils down to this: I really, really, really badly want to be good at what I’m doing (whatever that is) and am willing to work as hard as necessary in order to reach that goal. I’ve had my ups and downs with this strategy, but in the end it made me how I am and helped me to get where I am today.

I honestly believe that you can achieve much more than you might think (though some people prefer to tell you the opposite and are very resistant with that).

If you remain in your comfort zone you will not go any further

If you’re passionate about what you do, if you put yourself in the mood that you basically know nothing and that you can learn (in one way or another) from nearly anybody around you, if you accept that you will fail in one way or another and failing is ok if and only if you learn from failure, and last but not least if you accept that for the most of us being good at something actually is the result of continuous learning, hard work, deliberate practice and experience (as opposed to talent only), than you define what’s possible for you and not somebody else. At least that’s my way of thinking …

I’d like to think about myself as a developer, not as a C# developer, not as a OO developer, not as an ASP.NET developer, nor Javascript developer for that matters. Developer, just developer. Building awesome products in teams is my passion, but not building awesome products with technlogy X,Y or Z. Languages, technlogies are part of my toolset, not something I’m married to till death tears us apart.

Is that all?

It’s no big secret that being an engaged person that likes to think outside the box and not limits his views to the Microsoft way of building software, can sometimes have a hard time in the Microsoft ecosystem (especially if you like to work with teams and don’t want to go down the independent consultant road).

It’s utterly frustrating to hear from Microsoft evangelists that you’re not part of the target group for their product (!!! Visual Studio !!!) if you ask for more extensibility and less re-implementations of existing open source solutions (No shit, that really happened to me 1 month ago and I still can’t believe they actually said that).

I like the .NET framework and I especially like C#, but I’m more and more frustrated with their sales driven approach to software development. The frustrating part is that in the end I can understand why they bundle/entangle their products from a sales perspective. It’s probably my fault for not realizing earlier that this somewhat clashes with the idea of continuous improvement.

I sometimes tend to think that a greater part of us (of the .NET community) would live a lot happier professional live outside the MS ecosystem and those of us that do manage to pull that off inside that MS ecosystem have build themselves a beautiful oasis in a vast and wide desert.

My current project team is an example of the latter, using a mix of techniques from Lean, ATDD , BDD, with feature branching and extensive code review sessions. And all that is possible without the TFS and without 80% of the features of Visual Studio. Who would have thought that …

However this team is breaking apart at the end of the year and I’m in the position to start something new next year. Trying to get a new .NET team to the same state (or above) was an option, but I decided against that. Instead I decided to venture into new territory, to extend my toolkit with a new language and a new platform.

Why Ruby?

I skate to where the puck is going to be, not where it has been

I really, really like the quote, I really do, but do I think Ruby is the next big thing?

Honestly, I don’t

I don’t say this in any negative way. At the end of the end of the day Ruby is just a tool (though awesome tool) that can be used, misused and abused for getting things done.

What I’m more interested in is the Ruby community itself or even more precise the state of engineering practices in the community. From the outside they look far ahead than the common denominator in the Microsoft world. Lots and lots of .NET OSS frameworks and tools have been influenced by the Ruby community in one way or another.

The Moslems have a proverb, to understand a man, you’ve got to walk a mile in his shoes, whether they fit or not.

The Ruby community seems to be a great starting point for my venture. Lots of innovation going on, lots of passion involved, very OSS centered and goal orientated. However, I will never know for sure if those expectations hold up to the reality unless I work amongst them for a while.

So as you might have guessed, the focus of future posts will probably a lot less .NET centric …

I’m very exited to be part of this years speaker line up (though the quality of the line up is a bit intimidating ;-)). Both talks will be on the 20th of October in Track 4

• 10.05 – 11.05h, Introduction to Rhino.ServiceBus
• 15.20h – 16.20h, (ServiceBus) Patters for always responsive clients

Looking forward to see you there …

Most of the time of the past weekend I spend in Karlsruhe at the .NET Open Space Süd. To sum it up in 5 words: The event was a blast. I had an unbelievable amount of fun coding, chatting, learning with some of smartest people in the German .NET Community.

This was the 4th Open Space event I attended during the last 2 years and I think this one was the best so far. Why?

1. The content of the sessions I attended / participated in was really high quality. I learned something new in every fracking session. Every session was dense, focused and we had at least one participant who actually had extensive field experience in the related topic area. No CQRS session disaster this time ;-)
2. Overly generic topics ala “I want to talk about TDD” or “Let’s talk about (D)DDD” were the minority.

Besides that, one personal note: It was a blast to meet some of the guys I got to know throughout the last 2 years again and see the personal progression each of them has made. Guys, your awesome. Keep up your pace!

So, just to give you an idea about the sessions I attended here’s a quick sum-up of my weekend @NOS_SUED.

WTF is a Monad? (C# Edition)

The first day started with one of the hardest topics you might imagine, Monads. @sforkmann did a great job explaining the various basic monadic types and their implementation in C#. Helped me a lot to form a better picture of this abstract concept in my mind. Was nice to see the Maybe Monad implemented using query comprehension syntax (though we found out that the related msdn sample doesn’t compile aka sucks). Sadly we didn’t have time enough to take a look at Monads in F#. Homework, I guess.

Funny side note: The word “Monad” was present throughout the complete weekend. I guess the revelation that most of us have been using a Monad for quite a while now (in LINQ), though not knowing it, shocked quite a bunch of participants.

Git tips & tricks

Next up was @agross with Git. I never forgot that Alex was the person that told me about this “Git thing” two years ago, long before the topic suddenly started to get the attentions of the .NET OS community. Main focus of this session was the various approaches around conflict resolution and a detailed look at the difference between merging and rebasing.

Especially interesting was to hear a bit more about this experience with Git in the context of a popular .NET OS project (Alex is one of the core maintainers of MSpec).

Convention over Configuration

Halfway through Saturday I talked a bit about my experience with “Convention over Configuration”. My current project uses conventions a lot (but only for binding, thx @ilkerde for the clarification) and I’m really happy with the outcome so far. On retrospective I think @ilkerde, @agross and myself did a really good job in categorizing the various ways CoC can be applied from sourcecode, to builds to deployment.

BDD vs. ATDD

The biggest session I participated in was the (dunno what was the exact name of the session) “Behavior Driven Development vs. classic Acceptance Test Driven Development” session. Was cool to have @agross (MSpec maintainer), @ssishkin ( my personal Fitnesse guru), @sforkmann (creator of NaturalSpec), @DerAlbert and several others who’ve been doing BDD, something BDD-like or ATTD in a room and hearing their various war stories and views on the topic.

Introduction to Reactive Extensions

If you start a day with Monads to be consequent you need to end it with Monads, too. @sshishkin and @sforkmann gave an interesting talk about the ideas behind IObserver, IObservable and IQbservable. BTW, how cool is this IQbservable idea?

Specification By Example Do’s & Dont’ s

In this session we took a look at the various proven practices in BDD specification design and the other side of the coin, the different flavors of specification smells. We discussed the ObjectMother pattern, TestData Builder Pattern, modularization strategies for specs and especially the idea of having the specifications side-by-side with the actual production code in a single assembly. Very good to see other proponents of this idea.

I was literally blown away by finally seeing the grouping functionality for Visual Studio, I always wanted to have, alive. VsCommands, I’m going to install you today!

Behavior Driven Development BDD Framework - Shootout (MSpec vs. NaturalSpec vs. xUnit.BDDExtensions)

The (un)conference ended for me with a side-by-side comparison of different BDD frameworks. Several guys asked for this. I guess it makes sense when you’ve got the authors of 3 different frameworks for a particular topic together. Although I didn’t like the idea at first sight (I don’t like framework wars that much, besides in the end the idea of BDD matters, and not the tools) the session turned out to be a win for all of us. We demo-ed the typical bank transfer sample in each of the frameworks (MSpec, xUnit.BDDExtensions, NaturalSpec). Afterwards every framework owner demo-ed additional features more or less unique to the particular framework. I guess, each of us got ideas for “new” features ;-)

Closing thoughts

I really enjoyed being in Karsruhe. Big thx to the organization team for making this event possible. I hope to see some of you again at the Open Space in Leipzig later this year or same place next year.

Special thx to @agross, @sforkmann, @ilkerde, @roeb and @sshiskin for the intense and inside-full discussions. You rock guys!!!

One last advice: Don’t forget Jean Clojure’s basal monad

Two meetings ago we decided to do some coding on every meeting. The previous meeting we solved Kata FizzBuzz and on yesterday’s meeting we tried to dance with Roy Osheroves StringCalculator. We didn’t make it completely to the end, but I think we solved most of the Kata.

You can find yesterdays code at the end of this post. I’m sure in parts it smells a bit imperative and it definitely uses too much Regex - KungFu, but overall I’m pleased with the result. We’ve tried to incorporate the feedback we got on the Kata FizzBuzz code. I would love to get feedback on this one as well. What could be done better, cleaner or simply differently?

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91

open System
open System.Text.RegularExpressions
open Xunit

let shouldBeEqualTo a b = Assert.Equal(a,b)

let parse value =
    if String.IsNullOrEmpty(value) then 0 else
    match Int32.TryParse value with
    | (false,_) -> failwithf "Did not parse value %s" value
    | (true, n) when n < 0 -> failwithf "Negatives not allowed %s" value
    | (true, n) when n >= 1000 ->0
    | (true, n) -> n

let splitIntoDelimitersAndRest (calculationString:String) =
    let defaultDelmiters = [",";"\n"]
    let regex = new Regex("^//(?<defaultDelimiter>.*?)\\n(?<rest>.*)$", RegexOptions.Singleline)
    match regex.Match calculationString with
    | m when m.Success ->
        let delimiters = List.Cons(m.Groups.["defaultDelimiter"].Value, defaultDelmiters)
        (delimiters, m.Groups.["rest"].Value)
    | _ -> (defaultDelmiters, calculationString)

let add (calculationString:String) =
   let splitResult = splitIntoDelimitersAndRest calculationString
   let delimiters = fst splitResult |> List.toArray
   let rest = snd splitResult
   rest.Split(delimiters, StringSplitOptions.RemoveEmptyEntries)
   |> List.ofSeq
   |> List.map parse
   |> List.sum

[<Fact>]
let ``When an empty string is supplied it should return 0``() =
    String.Empty
    |> add
    |> (shouldBeEqualTo 0)
 
[<Fact>]
let ``When a single digit is supplied it should return the digits value``() =
    ["1"; "2"; "3"]
    |> List.map add
    |> List.iter2 shouldBeEqualTo [1;2;3]
 
[<Fact>]
let ``When two digits are supplied separated by a comma it should be able to some them up``() =
    ["1,2"; "3,4"; "4,5"]
    |> List.map add
    |> List.iter2 shouldBeEqualTo [3;7;9]

[<Fact>]
let ``When more than two digits are supplied separated by a comma it should be able to sum them up``() =
    ["1,2,4,5"; "3,4,5"; "4,5,6,7,8"]
    |> List.map add
    |> List.iter2 shouldBeEqualTo [12;12;30]

[<Fact>]
let ``When more than two digits are supplied separated by new line character be able to to sum them up``() =
    ["1\n2\n4\n5"; "3\n4\n5"; "4\n5\n6\n7\n8"]
    |> List.map add
    |> List.iter2 shouldBeEqualTo [12;12;30]
 
[<Fact>]
let ``When more than two digits are supplied separated by new line character or comma it should be able to some them up``() =
    ["1,2\n4,5"; "3,4\n5"; "4,5\n6\n7\n8"]
    |> List.map add
    |> List.iter2 shouldBeEqualTo [12;12;30]
 
[<Fact>]
let ``When more than two digits are supplied separated by a user supplied default delimiter it should be able to sum them up``() =
    ["//*\n1*2*4*5"; "//$\n3$4$5"; "//%\n4%5%6%7%8"]
    |> List.map add
    |> List.iter2 shouldBeEqualTo [12;12;30]

[<Fact>]
let ``When more than two digits are supplied separated by a user supplied default delimiter or one of the standard delimiters it should be able to sum them up``() =
    ["//*\n1*2*4*5"; "//$\n3$4$5"; "//%\n4\n5%6%7%8"]
    |> List.map add
    |> List.iter2 shouldBeEqualTo [12;12;30]
 
[<Fact>]
let ``When digits greater than 1000 are supplied it should ignore them``() =
    ["//*\n1*2000*4*5"; "//$\n3$4$1000"]
    |> List.map add
    |> List.iter2 shouldBeEqualTo [10;7]

[<Fact>]
let ``When using more than two digits with with a custom separator of multiple characters ít should be able to sum them up``() =
    ["//asdf\n1asdf4asdf5"; "//as\n3as4as"]
    |> List.map add
    |> List.iter2 shouldBeEqualTo [10;7]

This is what we came up with. (BTW: Partial function application and pipelining rocks !!!)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

open Xunit

let fizzBuzz number =
     match number with
     | n when n%15=0 -> "FizzBuzz"
     | n when n%3=0 -> "Fizz"
     | n when n%5=0 -> "Buzz"
     | _ -> number.ToString()

let areEqual expected actual =
     Assert.Equal(expected, actual)

[<Fact>]
let Should_return_the_digit_for_numbers_which_are_not_dividable_by_3_or_5()  =
    [1;2;11;13;16]
    |> List.map fizzBuzz
    |> List.iter2 areEqual ["1";"2";"11";"13";"16"]

[<Fact>]
let Should_return_Fizz_for_digits_dividable_by_3() =
    [3;6;9;12]
    |> List.map fizzBuzz
    |> List.iter (areEqual "Fizz")

[<Fact>]
let Should_return_Buzz_for_digits_dividable_by_5() =
    [5;10;20;25]
    |> List.map fizzBuzz
    |> List.iter (areEqual "Buzz")

[<Fact>]
let Should_return_FizzBuzz_for_digits_dividable_by_3_and_5() =
    [15;30;45;60]
    |> List.map fizzBuzz
    |> List.iter (areEqual "FizzBuzz")

If anyone of you hardcore functional guys out there notices something utterly wrong or something that could radically simplified, please let me know. We’re eager to learn more.

Possible runtime differences

xUnit.net 1.5 is compiled against the .Net Framework 3.5. If you’re using F# in combination with the VS2010 RC or RTM (like I do) you’ve got at least to options to make them work together.

• Use multi-targeting and configure the F# projects to compile for the .NET 3.5 runtime (Properties/Application/Target Framework).
• Update the app.config files of xunit.console.exe and xunit.gui.exe with a startup section and specify the .NET framework 4.0 version as supported.

1
2
3
4

 <startup>
  <supportedRuntime version="v4.0.30128" safemode="true"/> <!-- VS2010 RC -->
  <supportedRuntime version="v4.0.30319" safemode="true"/> <!-- VS2010 RTM -->
 </startup>

Pay attention to your parentheses

My choice was to update the xUnit.net configurations. After the update of the configuration files my assembly was loaded, however the test runner failed to detect my unit tests. As it turns out the open parentheses after a test function play an important role.

1
2
3
4
5
6
7
8
9

 [<Fact>]
 let After_converting_a_valid_data_row_the_title_should_have_been_extracted = //This compiles, but the test doesn't show up in the test runner.
    let row = convertDataRow "Test, 1234"
    Assert.Equal(fst(row), "Test")

 [<Fact>]
 let After_converting_a_valid_data_row_the_title_should_have_been_extracted() = //This will work fine
    let row = convertDataRow "Test, 1234"
    Assert.Equal(fst(row), "Test")

My first reaction was: WTF? But after reading some more chapters of "Real world functional programming" and a discussion at our local F# book club the behavior makes sense to me. My current understanding is that omitting the parentheses results in a different method signature. You can easily spot this in FSI:

• The first one is val After_converting_a_valid_data_row_the_title_should_have_been_extracted : unit
• The second one results in a val After_converting_a_valid_data_row_the_title_should_have_been_extracted : unit -> unit

What you can see here is that the first function signature doesn’t have a parameter while the second has a parameter of the type unit. One interesting difference between F# and C# is that the F# equivalent to C#’s void is an actual type called unit. The fun part is that () is it’s only value. Parentheses play a completely different role here ;-)

The xUnit test runner looks for methods with one unit parameter and a return type of unit. That’s why you need the parentheses.

Testing exceptions with xUnit.Net

One little subtlety I came across when testing exceptions is that you have to explicitly ignore the return value when you’re using Assert.Throws and pass in a method which doesn’t return unit. Feels a bit strange at first, but explainable. Again a signature mismatch. Assert.Throws expects a method with a unit -> unit signature. You have to do this in order to please the compiler. (If there’s a better way for this, please let me know)

1
2
3

[<Fact>]
let Trying_to_convert_an_invalid_format_throws() =
    Assert.Throws(fun () -> convertDataRow "FuBar" |> ignore)

The ignore function simply throws away any value it receives, returns a unit and makes the F# compiler happy.

Conclusion

I hope you saw in this post that testing F# with xUnit.net is actually pretty easy. It’s also a wonderful case for language interop on top of the CLR. Go see it for yourself :-)

The new code is actually easier. It should look something like this … .

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44

    public class ServicesAreSingletonsAndProxies : IRegistrationConvention
    {
        #region IRegistrationConvention Members

        public void Process(Type type, Registry registry)
        {
            if (!type.IsConcrete() || !IsService(type) || !Constructor.HasConstructors(type))
            {
                return;
            }

            Type pluginType = FindPluginType(type);

            if (pluginType == null)
            {
                return;
            }

            registry
                .For(pluginType)
                .Singleton()
                .Use(new ConfiguredInstance(type)
                {
                  Interceptor = new DynamicProxyInterceptor(pluginType)
                });
        }

        #endregion

        private static bool IsService(Type type)
        {
            return type.Name.EndsWith("Service");
        }

        private static Type FindPluginType(Type concreteType)
        {
            string interfaceName = "I" + concreteType.Name;

            return concreteType
                .GetInterfaces()
                .Where(t => string.Equals(t.Name, interfaceName, StringComparison.Ordinal))
                .FirstOrDefault();
        }
    }

What got me baffled

In his tweet he basically states (my translation from German to English) that

If a domain model consists only of POCOs it should be called data model

My first thought was a) does he mean anemic domain models and b) what has POCO to do with that? As I found out he didn’t mean anemic domain models. So let’s take a look at the POCO aspect.

POCO / POJO / PONO / POwhatever

The term exists in several variations and different programming languages. For the sake of simplicity I’m going to use POCO for the rest of the post since I’m a .NET guy, but same applies of course to all other versions. The English Wikipedia site defines the term “Plain Old CLR Object” as the following:

The term is used to contrast a simple object with one that is designed to be used with a complicated, special object frameworks such as an ORM component.
Another way to put it is that POCO’s are objects unencumbered with inheritance or attributes needed for specific frameworks …

To me personally, POCO is just a simple, but very important principle or guideline. POCO for me means, that you should strive to limit the contact area of your own code and the code of third party frameworks as much as possible. This includes staying away from third-party frameworks with heavy attribute usage and / or inheritance requirements. Why should you do this? 2 reasons seem to be important to me:

• Orthogonality. Two parts of a system, like features, components, classes, whatever are called orthogonal when changes in one don’t affect the other. Following a POCO approach in a solution can greatly support orthogonality in my personal experience. It helps you to design and build solutions that are easy to change and very adaptable to new requirements or frameworks (Ever tried to migrate a Microsoft CAB based solution?). Which leads to the second IMHO very important aspect:
• Reversibility. In the end of the day we’re all human. Sometimes we design the wrong way, sometimes the framework doesn’t work as expected, sometimes a particular framework isn’t exactly the right one any more when requirements change drastically. All those things happen. All those things can can come up in any project. POCO can help a lot in those situations, because it limits the impact of external frameworks or components to your code.

POCO mostly comes up in the context of an ORM solution. However, the concept of POCO is not directly bound to persistence or even domain models. Which leads me back to the entry of the post and Ralfs tweet. What is the main distinction between a domain model and something we might call a data model? In my opinion this is BEHAVIOR. The term POCO itself has nothing to do with behavior itself (at least from my perspective). Totally different aspects IMHO. So why should a model consisting of POCOs be called data model?

Am I fighting on lost ground here, missing something or confusing something?

Some of my older posts on the topic showed that the component responsible for Screen activation and deactivation in StoryTeller is the ScreenConductor. However, when the ScreenConductor activates or deactivates a Screen, it delegates a major part of work to the so called IShellService. The only implementer of this interface, the ShellService, is just a little facade around three things.

1. The ICommandbar, which is the main toolbar of StoryTeller,
2. the IOptionsMenu, which is a kind of Shortcut menu for StoryTellers Commands and
3. the IScreenObjectRegistry, which acts as a store / front-end for the current Command registration.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43

public class ShellService : IShellService
{
    private readonly ICommandBar _Commands;
    private readonly IOptionsMenu _options;
    private readonly IScreenObjectRegistry _registry;

    public ShellService(
          IScreenObjectRegistry registry,
          ICommandBar Commands,
          IOptionsMenu options)
    {
        _registry = registry;
        _Commands = Commands;
        _options = options;
    }

    #region IShellService Members

    public void ActivateScreen(IScreen screen)
    {
        _registry.ClearTransient();
        screen.Activate(_registry);
        refill();
    }

    public void ClearTransient()
    {
        _registry.ClearTransient();
        refill();
    }

    public void Start()
    {
        refill();
    }

    #endregion

    private void refill()
    {
        _Commands.Refill(_registry.Actions);
        _options.Refill(_registry.Actions);
    }

You can see some interesting aspects in the short code above.

1. The word transient appears several times. StoryTeller differentiates between two types of Commands: Permanent Commands and transient Commands. Permanent Commands are displayed, well permanently, while transient Commands are what I depicted as contextual Commands. They are Commands which should be only visible in a particular context.
2. Contextualization of Commands is handled on a per Screen basis in StoryTeller. Every time a Screen gets activated or deactivated the ICommandBar and the IOptionsMenu get reset and completely rebuild. With this you can have a very different Command UI depending on which Screen is activated.
3. The actual Command configuration in the Screen Activation Lifecycle is completely delegated to the active Screen. In his Activate() method he receives a reference to the IScreenObjectRegistry which can be used in order to start the Command configuration via a small fluent API.

1
2
3
4
5
6
7
8
9
10
11
12
13
14

public interface IScreenObjectRegistry
{
    //Gets a collection of all currently known command configurations  
    IEnumerable<ScreenAction> Actions { get; }

    //Removes all transient command configurations from the registry
    void ClearTransient();

    //DSL starting point for the configuration of transient Commands
    IActionExpression Action(string name);

    //DSL starting point for the configuration of permanent Commands
    IActionExpression PermanentAction(string name);
}

The following code snippet shows an example of how this API could be leveraged inside a Screen.

1
2
3
4
5
6
7
8
9
10
11
12

    public void Activate(IScreenObjectRegistry screenObjects)
    {
        screenObjects
            .Action("Save")
            .Bind(ModifierKeys.Control, Key.S)
             .To(_save); //This can be either Systen.Action or an System.Windows.Input.ICommand

        screenObjects
            .Action("Cancel")
            .Bind(Key.Escape)
            .To(_cancel);
    }

Gabriel Schenker has written an excellent series on how to write such a fluent API. Although it’s targeting Silverlight, most of the involved problems are explained in detail there, so forgive me if I don’t dive into the actual DSL implementation.

Some final thoughts

Making the Screen responsible for setting up his Commands makes a lot of sense to me, since the Screen is the unit which gets plugged into the UI infrastructure and it also very likely plays the role of the Command receiver in terms of the classic GoF pattern description. This doesn’t necessary mean that Screens are the only place for Command configuration. The initialization of modules in a Composite application is also a very likely place for registration of permanent Commands.

I consider having a fluent API for configuring the Commands also a plus, because it IMHO makes the actual Command configuration a lot easier and accessible. I’ve used the same setup (fluent API + delegation to screen) on my last 3 projects and it always worked for me like a charm.

Like I mentioned in the previous post, what I don’t like that much is the idea of mixing in visual aspects (Icon, Size, Location) into the Command configuration, mostly because I’ve been burned by this in the past when facing complex menus, like the ribbon. I think it’s a good idea to externalize the visual aspect via XML, at least for all the static stuff.

This is it

This was the last post about StoryTeller (at least for a while). It has been an interesting voyage which taught me a lot about UI infrastructure design, StructureMap usage and Convention over Configuration. Although it was primarily my learning excercise I hope you took something interesting with you from this blog series, too.

I’m going to continue my research on UI architecture with another deep dive into Rob Eisenbergs Caliburn soon. If your interested I would be very happy to have you with me on that trip …

Previously we used the standard ServiceInstaller / ServiceProcessInstaller tandem to integrate our services with MSI deployment. This does not work with Topshelf (since Topshelf does the service installation itself via the Registry). However it’s pretty easy to write a custom installer for that. You can do something like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

public class TopshelfInstaller : Installer
{
    private const string AssemblyIdentifier = "TopshelfAssembly";
    private const string InstallUtilAssemblyParameter = "assemblypath";

    public override void Install(IDictionary stateSaver)
    {
        var topshelfAssembly = Context.Parameters[InstallUtilAssemblyParameter];
        stateSaver.Add(AssemblyIdentifier, topshelfAssembly);

        RunHidden(topshelfAssembly, "/install");

        base.Install(stateSaver);
    }

    public override void Uninstall(IDictionary savedState)
    {
        var topshelfAssembly = savedState[AssemblyIdentifier].ToString();

        RunHidden(topshelfAssembly, "/uninstall");

        base.Uninstall(savedState);
    }

    private static void RunHidden(string primaryOutputAssembly, string arguments)
    {
        var startInfo = new ProcessStartInfo(primaryOutputAssembly)
        {
            WindowStyle = ProcessWindowStyle.Hidden,
            Arguments = arguments
        };

        using (var process = Process.Start(startInfo))
        {
            process.WaitForExit();
        }
    }
}

The interesting part is this line:

1

var topshelfAssembly = Context.Parameters[InstallUtilAssemblyParameter];

Took me some time to find this. During installation the Parameter Dictionary attached to the Context contains the full target filename of the assembly being installed (key is assemblypath). With this path you can directly launch the /install or /uninstall command for the Topshelf based exe.

HTH

P.S.: This resource pointed me in the right direction.

Is the basic GoF Command pattern sufficient for a modern composite application?

The basic GoF Command pattern has no notion of visual state of a Command, such as (Is)Enabled or (Is)Visible. Its original purpose was to encapsulate an action, so that it can be passed around and executed at some later point of time. Not more, not less.

1
2
3
4

public interface ICommand
{
  void Execute();
}

Obviously real world desktop apps need something a bit more sophisticated. I’ve seen several infrastructures in my (not so old) career so far (home grown as well as OS alternatives), which extended this basic idea with at least one of those properties mentioned above. Take for instance the P&P Composite UI Application Block (now better known as part of the Smart Client Software Factory). CAB implements a delegate based variation on the Command pattern. The delegate represents the action which is passed around. However, this delegate is managed by the Command class which has a notion of Status.

1
2
3
4
5
6

public enum CommandStatus
{
  Enabled, //visible and enabled
  Disabled, //visible and disabled 
  Unavailable //invisible 
}

The WPF Command infrastructure version of the Command interface is more like the original pattern and adds the Enabled Property and an EnabledChangedEvent to the interface definition.

1
2
3
4
5
6

public interface ICommand
{
  void Execute();
  bool Enabled { get; }
  event EventHandler EnabledChanged;
}

To be honest, the Command interface never looked like the original GoF definition in ANY APPLICATION or project I’ve worked on so far. It always had a slight modification in one or another way.

StoryTeller’s Command interface

StoryTeller is a WPF based application, so naturally it gets the WPF Command infrastructure out of the box. However it composes the WPF ICommand into a StoryTeller specific structure, the IScreenAction.

1
2
3
4
5
6
7
8
9
10

public interface IScreenAction
{
  bool IsPermanent { get; set; }
  InputBinding Binding { get; set; }
  string Name { get; set; }
  Icon Icon { get; set; }
  ICommand Command { get; }
  bool ShortcutOnly { get; set; }
  void BuildButton(ICommandBar bar);
}

IScreenAction extends the capabilities of the original GoF-Pattern with a lot of metadata, mostly for visual aspects (Icon, Description). If you’re wondering why he included visual aspects: That basically tries to solve a reoccurring problem in composite apps: In composite applications modules are not known at compile time to the infrastructure. Neither are all their capabilities and how they might be displayed in the infrastructure shell. Because of that, the infrastructure needs a dynamic, deferred way for doing the shells visual configuration at application startup. One way to implement this is to delegate the responsibility for setting this up to the modules itself. This can be done during the module load time or every time a screen is displayed. This fits very well with the idea of the Open Closed Principle, since adding new modules/screens doesn’t require any reconfiguration/recompilation of other modules or the infrastructure. This is more or less the approach that StoryTeller takes.

Some personal thoughts on IScreenAction

I’ve worked on three applications in the past which followed down the same road. One thing I noticed throughout those three applications is that this approach isn’t really well suited when you’ve got strict and/or complex requirements about how the UI of an application should look. Let me clarify a bit what I mean:

• The Ordering Problem. Even if you organize tools representing commands in a simple toolbar (as StoryTeller does) you can very easily get into situations where the product owner wants to have the tools in a very specific order which is different to module load order, some internal event order, whatever. I’ve encountered this several times now. First time we solved this by introducing a global constant class containing tool names. Very, very bad idea, do not repeat this. This introduces a kind of hidden temporal coupling, because now modules must be loaded in a particular order (so that a tool already exists to which we can refer by name). StoryTellers take on this is a bit better (but IMHO not much). The Icon class has an Integer based Order property. All tools get sorted based on this property in StoryTellers CommandBar when it’s reloaded. This is less coupled, because it eliminates the temporal aspect of the coupling, but still has coupling.
• API bloat with visual aspects. One area where I really started to find this approach annoying is when you stop having simple toolbars and start to use more complex menu types like for instance the Ribbon. Taking the ribbon as an example: Now don’t have simply an ordering problem, but at minimum an icon problem (Normal icon vs. Quick Access Toolbar), a size problem (Displayed large or small) and a positioning problem (/Tab/Group/ElementGroup vs. /ApplicationMenu/Left). We added all those stuff to our Command registration and guess what, we weren’t happy with that. We created a monster API actually doing very little.

So what do I (currently) prefer? Our current project (also using the Ribbon) completely strips the visual aspect of the Command. Our Command API looks very much like the WPF one, with the only addition of an Id property. The whole visual aspect is configured using an XML file which is loaded at application startup.

1
2
3
4
5
6
7

<Ribbon>
   <Tab>
      <Group>
         <Button imageId=”CancelIcon“ commandId=”CommandXYZ” />
      </Group>
   </Tab>
</Ribbon>

I think you get the point. It works very well for our scope. (Slight warning though: This solution might not be the best in case you need to represent menu state based on dynamically loaded data).

See you next time for: Commands strike back ;-)

It feels wrong to have registration and scanning in the Registry class

I absolutely second that. One of the decisions in my current project (a composite smart client) was to separate these two things, in order to give clear guidance on “which to use when”. Here is our setup:

1
2
3
4
5
6
7
8
9
10

ObjectFactory.Initialize(x =>
{
  x.AddRegistry(new InfrastructureRegistry());
  x.Scan(scanner =>
  {
          scanner.AssembliesFromPath("Modules");
          scanner.Convention<ProjectConventions>();
          scanner.LookForRegistries();
  });
});

• We packaged our conventions for the project into a single composite convention. This includes the easier mappings ala IFoo – Foo, as well as more complex conventions for services which are automatically instrumented on creation via Castle.DynamicProxy.
• Registry classes are used for all the stuff we’re not able to configure via conventions.
  This includes mappings from interfaces to types with completely different names, adding externally created stuff to the container or configuring complex constructions like a composite.
• There is exactly 1 Registry per module in our application (+ 1 for the infrastructure).
• Registry classes are dynamically found during the scan process by looking into each assembly configured in the Scanner.

Any opinions? If you’re using Registries, how do you use them?

It was an interesting experience mostly because I tried to re-use some code pieces for setting up conventions from an earlier project based on StructureMap 2.5.3. Quite a few things have been changed in the API. Needless to say, all for good. I just wanted to give a quick overview of the things I noticed.

ITypeScanner was replaced by IRegistrationConvention

If you wanted to write custom conventions in StructureMap 2.5.3 you needed to implement the ITypeScanner interface (An example is described here).

1
2
3
4
5
6
7
8
9
10
11

//StructureMap 2.5.3 
public interface ITypeScanner
{
  void Process(Type type, PluginGraph graph);
}
  
//StructureMap 2.5.4 
public interface IRegistrationConvention
{
  void Process(Type type, Registry registry);
}

As you can see, it’s not only a renaming. The signature of the Process-method has changed, too. It now uses the good old Registry class for doing the registration. Very consistent, good choice. Modifying the PluginGraph always left me with the feeling that I was digging too deep into the StuctureMap internals.

TypeRules base class has been replaced with Extension methods

In the past you could re-use some utility methods for reflection (like checking whether a type is concrete, etc.) by inheriting from the TypeRules class. This class has been completely removed, but the functionality is still available via Extension methods.

Lot’s and lot’s of renaming

A lot of renaming has been done. The most interesting stuff happened in the Registry class.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

//StructureMap 2.5.3
public class MyRegistry
{
    public MyRegistry()
    {
        ForRequestedType<IFoo>().TheDefaultIsConcreteType<Foo>();
        ForRequestedType<IBar>().TheDefaultIsConcreteType<Bar>().AsSingleton();

        ForRequestedType<IFoo>().TheDefault.IsThis(new Foo)
        ForRequestedType<IBar>().TheDefault.Is.ConstructedBy(x => new Bar());
    }
}

//StructureMap 2.5.4
public class MyRegistry
{
    public MyRegistry()
    {
        For<IFoo>().Use<Foo>();
        ForSingleton<IBar>().Use<Bar>();

        For<IFoo>().Use(new Foo)
        For<IBar>().Use(x => new Bar());
    }
}

The new version is a lot less wordier and a lot more consistent in naming. It also feels very familiar, although I’m unable to determine why.

Some new slick features I noticed

From playing around with the StructureMap trunk version during the “Diving into the StoryTeller Series” I already stumbled over this killer feature.

1
2
3
4
5

_container = new Container(x => x.Scan(s =>
{
   s.AssemblyContainingType<ISomeService>();
   s.ConnectImplementationsToTypesClosing(typeof(IHandler<>));
}));

Jimmy Bogard has already written an excellent article about that particular feature. So instead let us take a look at this new ability.

1

ObjectFactory.Model.GetAllPossible<IInitializable>();

This resolves all instances from the configuration model which implement the IInitializable interface.

Stuff you don’t see

If you’ve followed Jeremy D. Miller closely on Twitter you may have heard that the biggest change in the new release has happened under the hood of StructureMap. In previous versions StructureMap used Reflection.Emit to emit an assembly for the construction of the types at runtime. This has been completely rewritten using ExpressionTrees. I’m quite curious how he implemented that.

Feels like yet another source to learn has emerged ;-)

The Command Pattern

A lot of the content in this series dealt exclusively with how the StoryTeller UI layer manages Screens in its content area, but as you know most of the time an application consists of more parts than just the plain content area. A typical desktop application is probably going to have some sort of Mainmenu, a Statusbar and of course Contextmenus. Items displayed in those areas very often represent actions an application can perform. They act as a trigger of those actions. A typical way to implement this is using the GoF-Command Pattern, which separates the invoker of an action (for instance a button) from the receiver instance which executes the action by introducing the Command abstraction. A Command encapsulates the knowledge needed for an invokation of the receiver instance, so that it can be executed at a later time.

Commands are potentially contextual

An application can have lots and lots of Commands. While some of these Commands are available all of the time, some of them can only be executed in a particular context. A typical example for Commands of the first category might be the “Exit application” Command. A typical example for the latter category might be the “Undo” Command or “Redo” Command in all kinds of text editors, which can only be executed when the currently viewed document has some changes. It’s not uncommon to have lots of contextual Commands in an application that are only related to a very specific Screen or Screen state. When we think in terms of usability, the least a user should be able to take granted from an app is that the app appropriately shows which actions can be performed at a particular point of time. This can be achieved by enabling / disabling related items depending on the availability of the Command (be it manually or through databinding). Sometimes though,it might be a better approach to have an even more contextualized UI that only shows the commands related to the current context. So for instance if no code editor view is shown in Visual Studio than the “Undo” and “Redo” Commands should also not be visible (NOTE: VS doesn’t actually behave that way). I think this idea of contextualized UIs becomes more and more popular. Office 2007/2010 was build with this idea in mind.

Commands in a Composite UI

Composite UIs which follow the Open / Closed Principle add another problem to the mix. When new modules or new screens are loaded into a composite app, they shouldn’t need to modify the app infrastructure in order to add their related commands. The app infrastructure needs to provide a way to plug those commands in without modification. This also includes their visual representation (Text, Tooltip, Icon, etc.).

Questions we should take a closer look at

• Do we need to differentiate between types of Commands?
• Who is responsible for adding / registering commands?
• How is the visual representation of commands configured?
• Who is responsible for deciding whether Commands are available?
• Is there build-in .NET Framework support for this?
• Of course: How does StoryTeller implement all this?

I’m afraid that’s all for today. I wish you all merry Christmas and a happy new year. See you in 2010

http://www.twitter.com/BjoernRochel

Cheerz Björn

1. xUnit.BDDExtensions feature walkthrough and documentation Let’s be honest it’s currently not documented at all. I failed big time at documenting its usage scenarios and behavior so far. However, since more and more projects at my current client are starting to use it I’m definitely going to fix this …

2. Look into various options to implement the Active Object Pattern I’ve been reading several papers about infrastructures for command execution lately. It’s an interesting topic for distributed scenarios (for instance used in a CQSR design), but also for local scenarios when you start to think about multi core / concurrent programming. As modern applications are becoming more and more connected on the one hand and need to use local resources more efficiently on the other (because processors won’t get a lot faster in the near future) I think there’s a huge need for having a simple consistent design for both. Things I’d like to look into are the Concurrency Coordination Runtime, the .NET 4.0 Task Parallel Library and Application Spaces, as well as more specific topics like integrating such an infrastructure with an MVVM design.

3. Dive into the Caliburn trunk Last but not least I would love to spend some time with Caliburn since WPF is more and more on my radar and Caliburn seems to fully embrace and extend a lot of the original WPF design ideas in a composite context. I think I would do something similar to the StoryTeller series.

So, what do you think? Any preferences? Any priorities?

ScreenConductor vs. Application Controller

Before we dive into the actual code, let’s take a short break and talk a little bit about a more high level view on the ScreenConductor and the role the conductor is fulfilling in an application. Martin Fowler identified the pattern ApplicationController some years ago as

A centralized point for handling screen navigation and the flow of an
application.

It’s kind of a coordination structure which manages / coordinates the lifecylcle of child screens in an application as well as the lifecycle of the application shell itself (think about controlled shutdown for instance). You can think of the ApplicationController as a Facade client code can call in order to create/activate/deactivate screens in an application. This Facade defines a nice separation between application code on the one side and the UI infrastructure on the other side. It shields away implementation details of how the application is actually displaying screens (tab style, web style, etc) from the client and also provides a nice point for handling scenarios like dirty checks on screens. As an application grows over time, it’s a good idea to break down the ApplicationController into several collaborating classes and decouple its implementation details from another in order to make the system more manageable and maintainable. Adding a new screen to the application for instance should not require a change in one of the UI infrastructure classes. When breaking down the ApplicationController into several collaborating classes a good lead is to use the Single Responsibility Principle in order to identify responsibilities which can be extracted.

That’s exactly what Jeremy D. Miller did in his Screen Activation Lifecycle. He broke down the ApplicationController pattern into several smaller responsibilities, the most important beeing

• the ScreenCollection (which keeps track of all existing screens and the one beeing the active screen)
• the ScreenSubject (which is used to separate identification and creation of a screen from the screen itself)
• Screens (which provide the content beeing displayed and hooks for instance for the dirty check when the application closes)
• and the ScreenConductor.

Jeremy describes the ScreenConductor and its responsibilities as the following:

“Controls the activation and deactivation lifecycle of the screens within the application. Depending on the application, the conductor may be synchronizing the menu state of the shell, attaching views in the main panel or otherwise, and calling hook methods on the Presenter’s to bootstrap the screen. It may also be just as important to deactivate a screen when it’s made the inactive tab to stop timers. My first exposure to a ScreenConductor was an insurance application that was built with web style navigation. Anytime the user moved away from a screen we needed to check for “dirty” screens to give the user a chance to deal with unsaved work. On the other hand, we also had to check the entry into a requested screen to see if we could really open the screen based on pessimistic locking or permission rules. We pulled our a Layer SuperType for our Presenters for methods like CanLeave() and CanEnter(). The ScreenConductor would use these methods and others to manage screen navigation.”

To me the ScreenConductor is more or less an OCP-fied subset of the original ApplicationController pattern, focussing on the coordination and facade ideas of the original pattern.

A short episode in the Screen Activation Lifecycle

Let’s give our discussion a bit more detail. So far it was rather abstract. Before looking into the actual code I would like to walk you through a typical usecase which depicts how those components actually work together. The example Jeremy mostly uses for this is “Opening a source code file in Visual Studio” . I’m lazy, so I’m going to reuse this one.

“Consider you double-click a file in the Solution Explorer of VS. When you do this for the first time a new tab displaying the contents of the file will be opened. Doing the same thing a second time will not open a new tab, but rather focus the existing tab displaying the contents of the file.”

It’s actually easy to translate this story into a more abstract version using the responsibilities described in this post so far.

“Consider you want to open a Screen via a ScreenSubject. When the ScreenSubject detects that no related Screen is being displayed to the user, a new Screen will be created by the subject and then added to the ScreenCollection. Doing the same thing a second time will not open up a Screen, but rather activate the existing SCREEN, because the ScreenSubject detected that the Screen is already open.”

The interesting sidenode in this design is that from a client code perspective there is no difference between opening up a screen and activating a screen. Really nice …

Usecase: Opening a Screen

Now that you’re familiar with the first scenario, time to show some code. I’ve shown parts of this before in the previous post (Sorry for the duplication), but added some bits in order to illustrate this example. From the outside world a call to the ScreenConductor for this usecase might look like this.

1
2

var subject = new CSharpFileSubject(@"C:\\end\\of\\the\\world.cs");
screenConductor.OpenScreen(subject);

Notice that all data needed for creating the actual Screen will be passed in with the concrete ScreenSubject implementation.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

public class CSharpFileSubject : IScreenSubject
{
  private _fileName;

  public CSharpFileSubject(string fileName)
  {
    _fileName = fileName;
  }

  public bool Matches(IScreen screen)
  {
    return screen is SourceCodeScreen &&
      string.Equals((SourceCodeScreen)screen.FileName, _fileName));
  }

  public IScreen CreateScreen(IScreenFactory screenFactory)
  {
    var screen = screenFactory.Build<SourceCodeScreen>();
    screen.File = _fileName;
    return screen;
  }
}

This is not quite the code I would write for a real system, but I think you get the point. Two methods need to be implemented for the IScreenSubject interface. This is bool Matches(IScreen) which identifies a related screen and IScreen CreateScreen(IScreenFactory) which is used to create the screens. I really like this kind of API design since it gives you all sorts of extension points without the need to open up the actual infrastructure. Want to show a WaitCursor while you create the Screen? Go ahead. Want to do some loading before the screen is opened? Here’s the place to do it . . . Anyway, the ScreenConductors side of things looks like this.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

public virtual void OpenScreen(IScreenSubject subject)
{
  if (subject.Matches(_screens.Active))
  {
    return;
  }

  IScreen screen = findScreenMatchingSubject(subject);

  if (screen == null)
  {
    screen = createNewActiveScreen(subject);
  }
  else
  {
    activate(screen);
  }

  _screens.Show(screen); }

Pretty slick, isn’t it? The whole code is really dense. Most of the methods involved are not more than 5 lines long. Finding the related screen for instance is just a matter of a LINQ-Query on the ScreenCollection using the Matches method as its predicate.

1
2
3
4

private IScreen findScreenMatchingSubject(IScreenSubject subject)
{
  return _screens.AllScreens.FirstOrDefault(subject.Matches);
}

Creation of the target screen on the other hand is just a matter of handing the ScreenFactory (which is actually just a facade to the IoC-Container of choice) to the subject, activating the created Screen and adding it to the ScreenCollection.

1
2
3
4
5
6
7

private IScreen createNewActiveScreen(IScreenSubject subject)
{
  IScreen screen = subject.CreateScreen(_factory);
  activate(screen);
  _screens.Add(screen);
  return screen;
}

The last missing piece here is the actual activation of the Screen.

1
2
3
4

private void activate(IScreen screen)
{
  _shellService.ActivateScreen(screen);
}

This is delegated to the so called IShellService. You might ask yourself why this particular dependency exists (at least I did). The main purpose of this service is mostly the topic of registering Commands and filling up option panes related to the current Screen. This will be a post on its own, so don’t be mad at me, when I don’t cover it today. Instead I would like to take a look at another common use case:

Usecase: Closing a Screen

Now that we’ve seen how a Screen gets opened, let’s take a look at the other side of the coin, at how it’s closed.

1
2
3
4
5
6
7

public virtual void Close(IScreen screen)
{
  if (removeScreen(screen))
  {
    activateCurrentScreen();
  }
}

Most of the handling is in the removeScreen-method (btw, where does this convention of having all private methods beeing camel-cased come from? Is this some Java-exposure leaking through? ;-))

1
2
3
4
5
6
7
8
9

private bool removeScreen(IScreen screen)
{
  if (!screen.CanClose()) return false;

  _events.RemoveListener(screen);
  _screens.Remove(screen);
  _shellService.ClearTransient();
  return true;
}

It delegates the decision whether a screen can be closed to the screen and in case it can be closed, it removes the screen from the EventAggregator (_events), from the ScreenCollection (_screens) and clears its Command-registration (_shellService.ClearTransient()), before it activates the next screen becoming visible (in case there is one).

1
2
3
4
5
6
7
8
9

private void activateCurrentScreen()
{
  IScreen screen = _screens.Active;

  if (screen != null)
  {
    activate(screen);
  }
}

Usecase: App shutdown coordination

There is another common usecase implemented by the ScreenConductor I would like to show you. This is how the whole app shutdown is coordinated. Prerequesites for this: Instances interested in beeing notified when the user tries to shut the application down, need to a) implement the IClosable interface and b) be registered at the EventAggregator. The latter is done automatically for screens by the ScreenConductor.

1
2
3
4
5

public interface ICloseable
{
  void AddCanCloseMessages(CloseToken token);
  void PerformShutdown();
}

The IClosable interface just consists of two methods. void AddCanCloseMessage(CloseToken) is called in order to get feedback from listeners whether the application is allowed to be shutdown. You can think of CloseToken as a more or less extended version of CancelEventArgs.

1
2
3
4
5
6
7
8
9
10
11
12
13
14

public class CloseToken
{
  private readonly List<string> _messages = new List<string>();

  public string[] Messages
  {
    get { return _messages.ToArray();
  }

  public void AddMessage(string message)
  {
    _messages.Add(message);
  }
}

The following code piece is hooked into the Closing - event of StoryTellers main window (the shell). It heavily leverages the delegate based eventing of StoryTellers EventBroker in order to interact with all interested listeners.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

public bool CanClose()
{
  var token = new CloseToken();

  _events.SendMessage(x => x.AddCanCloseMessages(token));
  bool returnValue = true;

  if (token.Messages.Length > 0)
  {
    string userMessage = string.Join("\\n", token.Messages);
    returnValue = _messageBox.AskUser(CAN_CLOSE_TITLE, userMessage);
  }

  if (returnValue)
  {
    _events.SendMessage(x => x.PerformShutdown());
  }

  return returnValue;
}

One remark to the CanClose() code: _messageBox is just a small wrapper abstraction in order to make user interaction via message prompts testable. There’s nothing really fancy behind that. I really like the way the app shutdown is implemented. In fact we’ve added something very similar in my current project. However, I’m not so sure when it comes to the question whether this particular code piece should be part of the ScreenConductor. You could argue that this method has only very limited cohesion with the rest of the ScreenConductors methods. In fact most of the stuff the ScreenConductor interacts with (ScreenCollection, Screens, ScreenFactory, ScreenSubject) isn’t touched in this method. Besides that, it’s code that client application code normally IMHO doesn’t need to or even should call. In our current app we’ve extracted this responsibillity into a separate class called the ApplicationShutdownCoordinator because of that.

Some more impressions on StoryTellers ScreenConductor

The exposed API of the ScreenConductor is pretty small, actually only 6 “core” methods and some overloads. Most of the API really shines. However, besides the already mentioned CanClose() functionality, there is another functionality which in my opinion should not be in the ScreenConductor. Can you spot it?

LoadHierarchy(Func<Hierarchy>)) looks a bit misplaced to me because it seems to work on a different abstraction level than the rest of the methods. It looks very application specific, while the rest of the StoryTeller APIs look very general purpose (independent from the fact whether Jeremy actually wanted to achieve this or this being just the result of applying good design practices). Same applies to one of the messages / events the ScreenConductor is registered for at the EventBroker, namely DeleteTestMessage. I don’t think it should be directly handled in the ScreenConductor.

A static code analysis might indicate that the ScreenConductor has too many dependencies. In fact there’re 7 direct dependencies injected into the constructor,

• IEventAggregator
• IScreenCollection
• IScreenFactory
• IApplicationShell
• IShellService
• IScreenObjectLocator
• IMessageCreator

6 transient dependencies (method parameters or local scope),

• IScreen
• IScreenSubject
• CloseToken
• UserScreenActivation
• OpenItemMessage
• DeleteTestMessage

and 3 Message interests

• UserscreenActivation
• OpenItemMessage
• DeleteTestMessage

in the ScreenConductor class. Sounds pretty heavy and like a refactoring candidate at first. However, as I mentioned earlier, the ScreenConductor is mostly a Facade with some additional coordination logic in it. When I say “some additional coordination logic” I mean this literally. ScreenConductor has just round about 250 LOC.

I’m totally ok with this. It certainly has some potential for optimization of the dependencies (IScreenObjectLocator seems to be at least partially obsolete, IApplicationShell and IShellService could be merged I guess), but even without that I consider it a really good example of strong extensible design for composite desktop apps. For me personally the ScreenConductor fills a really important gap in the p&p composite app guidance (be it CAB / SCSF or PRISM). I always had the feeling that I’m missing something there, but was unable to point out exactly what I’ve been missing. This feeling mostly came up when I added some screen activation or screen creation logic in places that didn’t felt right. Now I know why. Interestingly others observed the need for something similar as well. Having a ScreenConductor in your application makes IMHO the whole UI infrastructure a lot more approchable and easier to understand.

Some final thoughts

I left the rest of the ScreenConductors code out of this post intentionally, because if there’s one thing I’d like you to take from this post or even the complete series is that StoryTeller is a really good learning resource. I really value, what I’ve learned from the Dovetail guys while inspecting the code. I wish I had done this earlier. Good design matters. If you’re looking for a place to learn more about it, the StoryTeller codebase might just be the place for you. See you next time, when we take some time to dig into the command structure of StoryTeller …

Today is all about displaying Notifications in the UI

This post will guide you through all the steps I took in order to achieve the affect I demonstrated in the introduction post. Last time I showed how I’m transfering Notifications from the ViewModel into the logical WPF tree. If you’ve not read the previous posts, please give them some minutes, because I’m not going to repeat a lot of them today. You can find them here, here and here. As always, a quick reminder:

What I’m showing is in this series is how I’ve implemented the Notification Pattern. I’m not claiming that it’s the only or the best way to do so. However, it’s the one that works very good for me.

How to get the red border effect

The red border has to be displayed when Notifications exists for a control. Technically this means that the attached property Notifications (which is defined on the ValidationBehavior class I showed in the last post) is set to a non empty NotificationCollection. We can react to this by defining a DataTrigger for this. In my own words I would describe a DataTrigger as

An in XAML defined event handler with a related criteria. When the criteria is matched the DataTrigger gets executed. When it isn’t matched any more, the DataTrigger reverts the state of the element on which it’s defined to the state before it was executed.

Sounds usable for our purpose. Think about it, we only want to show the red border, when the attached property is set to a non empty collection. If the property is reset the border needs to disappear. The only difficulty with DataTriggers we need to solve on our way is how to configure that exactly in XAML. DataTriggers can be easily set on primitives (such as string, bool, etc.) or null, but there isn’t an out of the box way for setting our criteria in XAML. However you can use a custom Converter for converting our value to a primitive “switch”.

1
2
3
4
5
6
7
8
9
10
11
12
13

[ValueConversion(typeof(NotificationCollection), typeof(bool))]
public class ContainsNotificationConverter : IValueConverter
{
  public object Convert(object value, Type targetType, object parameter, CultureInfo culture)
  {
    return (value != null && value is NotificationCollection && ((NotificationCollection)value).Any());
  }

  public object ConvertBack(object value, Type targetType, object parameter, CultureInfo culture)
  {
    throw new NotSupportedException();
  }
}

Using this converter we can define our DataTrigger in the Style for Controls like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

<Fx:ContainsNotificationConverter x:Key="notificationConverter" />

<Style TargetType="Control">
     <Setter Property="Fx:ValidationBehavior.IsEnabled" Value="true" />
     <Style.Triggers>
         <DataTrigger
             Binding="{Binding Path=(Fx:ValidationBehavior.Notifications),
             Converter={StaticResource notificationConverter},
             RelativeSource={x:Static RelativeSource.Self}}" Value="true">
             <Setter Property="BorderBrush" Value="Red" />
             <Setter Property="BorderThickness" Value="2" />
         </DataTrigger>
     </Style.Triggers>
 </Style>

How to display Notifications in a Tooltip

Solving the Tooltip requirement was a bit more tricky (at least for me). It took me quite some time to figure out how to do this in WPF. The solution I’m going to show uses only XAML based code.

1. Integrating the Tooltip into the DataTrigger

We simply use our DataTrigger to automatically set the tooltip of a Control in case Notifications exist.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

<ToolTip x:Key="ValidationErrorTooltip" />

<Style TargetType="Control">
     <Setter Property="Fx:ValidationBehavior.IsEnabled" Value="true" />
     <Style.Triggers>
         <DataTrigger
             Binding="{Binding Path=(Fx:ValidationBehavior.Notifications),
             Converter={StaticResource notificationConverter},
             RelativeSource={x:Static RelativeSource.Self}}" Value="true">
             <Setter Property="BorderBrush" Value="Red" />
             <Setter Property="BorderThickness" Value="2" />
             <Setter Property="ToolTip" Value="{StaticResource ValidationErrorTooltip}" />
         </DataTrigger>
     </Style.Triggers>
 </Style>

Now the UI looks really crappy. The tooltip is not recognizable as one.

2. Using a ControlTemplate to style the Tooltip

In order to shape the appearance of the tooltip we can use XAML Styles again. You can change the whole visual appearance of a Control using Styles and ControlTemplates. The template I defined consists mostly of a DockPanel containing a Label (which provides the tooltips caption) and a TextBlock (which will later contain the Notification messages).

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39

<Style x:Key="ErrorTooltipSyle" TargetType="ToolTip">
    <Setter Property="Template">
        <Setter.Value>
            <ControlTemplate TargetType="ToolTip">
                <Border BorderBrush="Black" BorderThickness="1">
                    <DockPanel>
                        <Label DockPanel.Dock="Top"
                          FontWeight="Bold"
                          Background="Red"
                          Foreground="White"
                          Content="Validation Error" />
                        <TextBlock
                          Padding="10"
                          Background="White"
                          Foreground="Black"
                          TextWrapping="WrapWithOverflow" />
                    </DockPanel>
                </Border>
            </ControlTemplate>
        </Setter.Value>
    </Setter>
</Style>

<!-- Notice the defined Style -->
<ToolTip x:Key="ValidationErrorTooltip" Style="{StaticResource ErrorTooltipSyle}" />

<Style TargetType="Control">
    <Setter Property="Fx:ValidationBehavior.IsEnabled" Value="true" />
    <Style.Triggers>
        <DataTrigger
            Binding="{Binding Path=(Fx:ValidationBehavior.Notifications),
            Converter={StaticResource notificationConverter},
            RelativeSource={x:Static RelativeSource.Self}}" Value="true">
            <Setter Property="BorderBrush" Value="Red" />
            <Setter Property="BorderThickness" Value="2" />
            <Setter Property="ToolTip" Value="{StaticResource ValidationErrorTooltip}" />
        </DataTrigger>
    </Style.Triggers>
</Style>

Our UI now looks like this.

Not as crappy as before but we’re not finished yet, because we’re not displaying Notifications yet.

3. Define Databinding on the Tooltip

Defining the Databinding was probably the hardest step I had to take. The problem is that you need to get the NotificationCollection from the Control the tooltip is displayed on. Being not a WPF pro figuring out how to do this took quite some time. Anyway, in order to get the Notification there isn’t much you need to do. The trick is to bind against the property PlacementTarget on the ToolTip class itself. This property holds the reference to the Control on which the Tooltip instance is displayed. All we need to do is to add a Binding to the Style definition that sets the DataContext of the ToolTip to the related control.

1
2
3
4
5

<Style x:Key="ErrorTooltipSyle" TargetType="ToolTip">
    ...
    <Setter Property="DataContext" Value="{Binding Path=PlacementTarget, RelativeSource={x:Static RelativeSource.Self}}" />
    ...
</Style>

The next step we need to take is setting up the Binding for our attached property Notifications. Because a NotificationCollection can contain more than one Notification I used the ItemsControl for displaying them in the content area of the tooltip.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

<Style x:Key="ErrorTooltipSyle" TargetType="ToolTip">
  <Setter Property="DataContext" Value="{Binding Path=PlacementTarget, RelativeSource={x:Static RelativeSource.Self}}" />
    <Setter Property="Template">
        <Setter.Value>
            <ControlTemplate TargetType="ToolTip">
                <Border BorderBrush="Black" BorderThickness="1">
                    <DockPanel>
                        <Label DockPanel.Dock="Top"
                          FontWeight="Bold"
                          Background="Red"
                          Foreground="White"
                          Content="Validation Error" />
                        <TextBlock
                          Padding="10"
                          Background="White"
                          Foreground="Black"
                          TextWrapping="WrapWithOverflow">

                            <!-- This control displays our Notifications -->
                            <ItemsControl x:Name="notifications"
                                HorizontalAlignment="Stretch"
                                Margin="10"
                                VerticalAlignment="Center"
                                ItemsSource="{Binding Path=(Fx:ValidationBehavior.Notifications), Mode=OneWay}"/>

                         </TextBlock>
                    </DockPanel>
                </Border>
            </ControlTemplate>
        </Setter.Value>
    </Setter>
</Style>

Voila, our Notifications are finally displayed in the UI.

4. Styling the Notifications

In my initial post I showed a hyphen in front of each Notification. This is fairly easy to add, too. All you have to do is to define a DataTemplate for the Notification class and set it as the ItemTemplate of the ItemsControl we’re using.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41

<!-- Very simple data template -->
<DataTemplate x:Key="NotificationTemplate">
    <StackPanel Orientation="Horizontal">
        <TextBlock>-</TextBlock>
        <TextBlock x:Name="notification" Text="{Binding}" />
    </StackPanel>
</DataTemplate>

<Style x:Key="ErrorTooltipSyle" TargetType="ToolTip">
  <Setter Property="DataContext" Value="{Binding Path=PlacementTarget, RelativeSource={x:Static RelativeSource.Self}}" />
    <Setter Property="Template">
        <Setter.Value>
            <ControlTemplate TargetType="ToolTip">
                <Border BorderBrush="Black" BorderThickness="1">
                    <DockPanel>
                        <Label DockPanel.Dock="Top"
                          FontWeight="Bold"
                          Background="Red"
                          Foreground="White"
                          Content="Validation Error" />
                        <TextBlock
                          Padding="10"
                          Background="White"
                          Foreground="Black"
                          TextWrapping="WrapWithOverflow">
                          <ItemsControl x:Name="notifications"
                                HorizontalAlignment="Stretch"
                                Margin="10"
                                VerticalAlignment="Center"
                                ItemsSource="{Binding Path=(Fx:ValidationBehavior.Notifications), Mode=OneWay}"

                                <!-- This uses configures our template for Notifications -->
                                ItemTemplate="{StaticResource NotificationTemplate}" />

              </TextBlock>
                    </DockPanel>
                </Border>
            </ControlTemplate>
        </Setter.Value>
    </Setter>
</Style>

DataTemplates are also the weapon of choice if you want to display errors in a different fashion than warnings (for instance by displaying a different icon). This is where we arrived:

Closing thoughts

What I like about the current solution is that it demonstrates in a nice way how different the programming model of WPF actually is compared to WinForms. The only imperative code we have is the code that transfers Notifications from our ViewModel into the logical tree. That’s it. The rest, the complete visual appeal of the Notifications, is a separated concern. Those two things can be changed independently from each other, even by different roles in a development team (Designer/Developer). Besides that I like the way the composition based WPF model helps my application code to stay focused and clean with only minimum implementation constraints on the ViewModel itself (the INotificationSource interface). There’re certainly things to improve both in XAML and in the glue code but I consider it a good start to build on …