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 started 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 Kata 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?

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 !!!)

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.

1. Use multi-targeting  and configure the F# projects to compile for the .NET 3.5 runtime (Properties/Application/Target Framework).
2. 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.

   
        <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.

     [<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 while 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)

    [<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 . . . .

    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 / POwhateverO

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 side 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.

    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.

    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.

        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:

    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:

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.

Let’s take a look at some of the questions I left unanswered in the last post.

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.

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.

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.

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.

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);
}

ScreenAction 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.

<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