Devlicio.us - Just the Tasty Bits

“Build Your Own MVVM Framework” is Online

Rob Eisenberg — Tue, 16 Mar 2010 22:37:00 GMT

Yesterday I delivered my talk, “Build Your Own MVVM Framework,” at Mix. Thanks to all who came out to listen and allow me a short time to share some of my ideas. I’m very grateful to have had this opportunity. Thanks also to all who voted for the talk. If you were not able to make it in person, Microsoft has made the video of the session available online along with the slides. You can now watch it at http://live.visitmix.com/MIX10/Sessions/EX15. I’m also providing the full source code for the sample application as an attachment to this blog post. If you look at the source code, there are a few things to keep in mind:

The backend is fake.
The framework is not intended to be used “as is.” It was built for this specific application. You should adapt it to your application, or use Caliburn, which was designed for general use.
There are a number of other interesting things in the sample, which I did not discuss in the talk. It’s worth poking around a little bit…

I hope this talk and sample give you some ideas. I would love to hear your feedback. Enjoy!

Are You Playing Checker or Chess? - YAGNI Revisited

Tim Barcz — Mon, 15 Mar 2010 05:08:37 GMT

This past Saturday I had an early morning coffee with a friend. He’s an entrepreneurial type – a big thinker who moves at a fast pace and is always thinking ahead. One question he asked of me, “Are you playing checkers or chess?”.

The question was asked around business and career but I could not help but think of the implications to software.

In the agile software world we often use the mantra…”do the simplest thing that works”. I have found that I cringe at the usage of that statement at certain points (when honest - even at my own usage at times upon later reflection). Really, if we step back and honestly evaluate ourselves, how often do we really implement the simplest thing that works. My opinion is that it’s often used as an excuse to get get out of work - a “wild card” of sorts that’s pulled out when convenient.

With “the simplest thing that works”, developers associate the term YAGNI – You Ain’t Gonna Need It. While very often true – you really don’t need that feature (studies have demonstrated and confirmed) – I see times where people confuse YAGNI and the agile principle of “the simplest thing that works”. What’s the difference?

Chess versus checkers my friend. Checkers is a pretty simple game with few rules and even fewer game pieces. Chess however has several game pieces, each of which has their own movements and rules associated with them. The types of discussions and strategies that exist around chess do not exist around checkers. Put simply, chess is much more complex than checkers. Checkers is really treated on a move-by-move basis whereas chess is far more strategic, where moves are setup far in advance of their execution.

When talking about “the simplest thing that works” we have to be careful to not be playing checkers. Play chess instead. Make a small, single move that moves you closer to some strategic end. Like it or not, many waterfall processes are playing chess – trying to anticipate every outcome or piece of functionality and adjust/account for it. What the waterfall practitioner fails to see is the inevitable change. Many agile adopters start playing checkers, making small move after small move, assuaging fears of downstream problems with the comfort that their doing the simplest thing that works.

Therefore, have a strategy, a end in mind, and then do the simplest thing that works that moves you closer to that end. Note however that this may not always be the absolute simplest thing that works.

UppercuT – Custom Extensions Now With PowerShell and Ruby

Rob Reynolds — Sun, 14 Mar 2010 01:43:27 GMT

Arguably, one of the most powerful features of UppercuT (UC) is the ability to extend any step of the build process with a pre, post, or replace hook. This customization is done in a separate location from the build so you can upgrade without wondering if you broke the build.

There is a hook before each step of the build has run. There is a hook after. And back to power again, there is a replacement hook. If you don’t like what the step is doing and/or you want to replace it’s entire functionality, you just drop a custom replacement extension and UppercuT will perform the custom step instead.

Up until recently all custom hooks had to be written in NAnt. Now they are a little sweeter because you no longer need to use NAnt to extend UC if you don’t want to. You can use PowerShell. Or Ruby. Let that sink in for a moment. You don’t have to even need to interact with NAnt at all now.

Extension Points

On the wiki, all of the extension points are shown. The basic idea is that you would put whatever customization you are doing in a separate folder named build.custom. Each step Let’s take a look at all we can customize:

The start point is default.build. It calls build.custom/default.pre.build if it exists, then it runs build/default.build (normal tasks) OR build.custom/default.replace.build if it exists, and finally build.custom/default.post.build if it exists. Every step below runs with the same extension points but changes on the file name it is looking for. NOTE: If you include default.replace.build, nothing else will run because everything is called from default.build.
- policyChecks.step
- versionBuilder.step NOTE: If you include build.custom/versionBuilder.replace.step, the items below will not run.
  - svn.step, tfs.step, or git.step (the custom tasks for these need to go in build.custom/versioners)
- generateBuildInfo.step
- compile.step
- environmentBuilder.step
- analyze.step NOTE: If you include build.custom/analyze.replace.step, the items below will not run.
  - test.step (the custom tasks for this need to go in build.custom/analyzers) NOTE: If you include build.custom/analyzers/test.replace.step, the items below will not run.
    - mbunit2.step, gallio.step, or nunit.step (the custom tasks for these need to go in build.custom/analyzers)
  - ncover.step (the custom tasks for this need to go in build.custom/analyzers)
  - ndepend.step (the custom tasks for this need to go in build.custom/analyzers)
  - moma.step (the custom tasks for this need to go in build.custom/analyzers)
- package.step NOTE: If you include build.custom/package.replace.step, the items below will not run.
  - deploymentBuilder.step

Customize UppercuT Builds With PowerShell

UppercuT can now be extended with PowerShell (PS). To customize any extension point with PS, just add .ps1 to the end of the file name and write your custom tasks in PowerShell.

If you are not signing your scripts you will need to change a setting in the UppercuT.config file. This does impose a security risk, because this allows PS to now run any PS script. This setting stays that way on ANY machine that runs the build until manually changed by someone. I’m not responsible if you mess up your machine or anyone else’s by doing this. You’ve been warned.

Now that you are fully aware of any security holes you may open and are okay with that, let’s move on.

Let’s create a file called default.replace.build.ps1 in the build.custom folder.

Open that file in notepad and let’s add this to it:

write-host "hello - I'm a custom task written in Powershell!"

Now, let’s run build.bat.

You could get some PSake action going here. I won’t dive into that in this post though.

Customize UppercuT Builds With Ruby

If you want to customize any extension point with Ruby, just add .rb to the end of the file name and write your custom tasks in Ruby. Let’s write a custom ruby task for UC. If you were thinking it would be the same as the one we just wrote for PS, you’d be right!

In the build.custom folder, lets create a file called default.replace.build.rb.

Open that file in notepad and let’s put this in there:

puts "I'm a custom ruby task!"

Now, let’s run build.bat again.

That’s chunky bacon.

UppercuT and Albacore.NET

Just for fun, I wanted to see if I could replace the compile.step with a Rake task. Not just any rake task, Albacore’s msbuild task. Albacore is a suite of rake tasks brought about by Derick Bailey to make building .NET with Rake easier. It has quite a bit of support with developers that are using Rake to build code.

In my build.custom folder, I drop a compile.replace.step.rb. I also put in a separate file that will contain my Albacore rake task and I call that compile.rb.

What are the contents of compile.replace.step.rb?

rake = 'rake'
arguments= '-f ' + Dir.pwd + '/../build.custom/compile.rb'

#puts "Calling #{rake} " + arguments
system("#{rake} " + arguments)

Since the custom extensions call ruby, we have to shell back out and call rake. That’s what we are doing here. We also realize that ruby is called from the build folder, so we need to back out and dive into the build.custom folder to find the file that is technically next to us.

What are the contents of compile.rb?

require 'rubygems'
require 'fileutils'
require 'albacore'

task :default => [:compile]

puts "Using Ruby to compile UppercuT with Albacore Tasks"
desc 'Compile the source'
msbuild :compile do |msb|
  msb.properties = { :configuration => :Release, :outputpath => '../../build_output/UppercuT' }
  msb.targets [:clean, :build]
  msb.verbosity = "quiet"
  msb.path_to_command = 'c:/Windows/Microsoft.NET/Framework/v3.5/MSBuild.exe'
  msb.solution = '../uppercut.sln'
end

We are using the msbuild task here. We change the output path to the build_output/UppercuT folder. The output path has “../../” because this is based on every project. We could grab the current directory and then point the task specifically to a folder if we have projects that are at different levels. We want the verbosity to be quiet so we set that as well.

So what kind of output do you get for this? Let’s run build.bat

custom_tasks_replace:

     [echo] Running custom tasks instead of normal tasks if C:\code\uppercut\build\..\build.custom\compile.replace.step exists.
     [exec] (in C:/code/uppercut/build)
     [exec] Using Ruby to compile UppercuT with Albacore Tasks
     [exec] Microsoft (R) Build Engine Version 3.5.30729.4926
     [exec] [Microsoft .NET Framework, Version 2.0.50727.4927]
     [exec] Copyright (C) Microsoft Corporation 2007. All rights reserved.

If you think this is awesome, you’d be right!

With this knowledge you shall build.

Come Hang at Mix…MVVM Style

Rob Eisenberg — Sun, 14 Mar 2010 00:07:00 GMT

Tomorrow I kiss the wife and baby goodbye (sadly) and hop on a plane heading to Mix in Las Vegas. This year I have the unique honor and privilege to present “Build Your Own MVVM Framework.” I’ll be speaking Monday afternoon at 3:30 PM in Lagoon F. Here’s the official description of my talk:

You’ve heard a lot about MVVM, but you’ve struggled to see how it can help you in your day to day work. Or, you are experienced at implementing MVVM, but looking for some ways to maximize on your investment in this methodology. In this talk, we look at a simple MVVM application and see how a small, application-specific framework can help eliminate pain points in our UI development and provide simple and effective solutions. Attendees will walk away with code, but more importantly with an understanding of how to apply some simple ideas to improve productivity with MVVM in their own projects.

This is an intermediate level discussion of MVVM and presupposes knowledge of either WPF or Silverlight and a grasp of the basic MVVM pattern. If you are new to MVVM, let me encourage you to attend Laurent Bugnion’s talk “Understanding the Model-View-ViewModel Pattern,” conveniently scheduled just before me at 2:00pm in Lagoon F.

During the conference, I’m planning to spend plenty of time in the lounge. I’ll probably be working on Caliburn :) If you’re interested in Caliburn and will be at Mix, let me know. If there is enough interest, I can do a small demo/presentation in the lounge at some point. I’m looking forward to seeing you there and thank you to everyone who voted for my talk!

Versioning REST Services

Scott Seely — Sat, 13 Mar 2010 19:01:00 GMT

I’ve always been intrigued by the versioning problem. The versioning problem works like this: you build an API (Application Programming Interface) to get some work done. That API is successful and consumers ask for enhancements to the API. At this point, you have a problem: how do you support everyone who uses the current API while adding enhancements? If you have been down this road, you know that you have to solve the problem early—before success.

The way you handle versioning varies. With compiled code and libraries, you send out a new DLL/Assembly/JAR file and tell folks to convert existing code when they have a chance. With Web services, including SOAP, REST, and just HTTP accessible ones, you have other issues. You typically want a single code base to consume the old and updated messages. Given that many of us are now writing REST services, I talked to InformIT about the need for an article explaining how to version these JSON/XML speaking endpoints. That article is now live and available for your reading at http://www.informit.com/articles/article.aspx?p=1566460.

ASP.NET: Cannot use a leading .. to exit above the top directory

Michael C. Neel — Fri, 12 Mar 2010 20:09:00 GMT

This is a really quick post, mostly for myself so the next time I have this issue I can find the answer (yes, I often search my blog before google).

The error “Cannot use a leading .. to exit above the top directory” can be thrown by ASP.NET when you use relative paths incorrectly. If you generate a url with too many “../../../” levels in it that would take the user above the root directory, you can generate the exception.

Why the exception? Security I guess, but it’s a client URL and the server should know better than let the internet walk the C drive, but at one time a company in Redmond had servers with just such issues. My problem isn’t with the unneeded exception (after all, it would just be a 404 link worst case), but with the bug in ASP.NET that causes it.

If you are using Server.Transfer or HttpContext.RewritePath to redirect a request (say map it to a template page) and have a HyperLink control with the ImageUrl property set, you win an extra “../” by the framework. The fix is to wrap the HyperLink control around an Image control.

In code, if you have:

<asp:HyperLink runat="server" NavigateUrl="~/FlyPage.aspx"
    ImageUrl="~/Images/DeadFly.png" Width="200" Height="200"/>

Change it to:

<asp:HyperLink runat="server" NavigateUrl="~/FlyPage.aspx">
    <asp:Image runat="server" ImageUrl="~/Images/DeadFly.png"
    Width="200" Height="200" />
</asp:HyperLink>

(I said it was a quick post… now go register for CodeStock!)

dotTrace 3.1 64-bit disabled inside Visual Studio 2008

sergiopereira — Fri, 12 Mar 2010 18:15:00 GMT

I work on a web application and I use dotTrace when some profiling is needed. The problem is that I cannot fire off doTrace directly from inside Visual Studio 2008 because the commands and toolbar icons to launch it are permanently disabled. Well, not anymore.

Background

The web application I work on is a 64-bit application. I use a 64-bit version of Windows (namely, Win2008 x64). I installed the 64-bit version of dotTrace 3.1 and it does work stand-alone but it never worked integrated with VS 2008, which is a shame because it contains some neat features like it's enabling the ReSharper test runner to run the chosen test(s) directly under dotTrace profiling. The screen shot below shows how it should look like but on my box these dotTrace commands were simply disabled.

The fix

After much disappointment with the missing features, my fellow Devlicio.us blogger Hadi Hariri put me in contact with Oleg Stepanov.

The first suggestion was trying the 32-bit version of dotTrace, which wasn't an option for me because, as I said, my application and all the supporting utilities are 64-bit, it runs under a 64-bit process, so that's ultimately how I need to profile it.

Then Oleg explained that the problem is that VS is a 32-bit application and it was looking for a registry key in the wrong place, not finding it, and then it was assuming dotTrace wasn't available.

Hmmm... That sounded eerily familiar, didn't it? Once again the little annoyances of developing 64-bit code with 32-bit tools come to bite us.

To fix the problem, just like the other time it happened, we just need to copy the right registry key to its corresponding place under the Wow6432Node key.

Open the Registry Editor and go to the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\ key. One of its GUID-named subkeys will contain the dotTrace information. Just search for dotTrace and find the right subkey. Now just copy (or export/edit/import) that key under HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\ and you're ready to restart Visual Studio and see all the integrated dotTrace features come alive.

Advanced Castle Windsor – generic typed factories, auto-release and more

Krzysztof Koźmic — Thu, 11 Mar 2010 20:13:00 GMT

This post is a playground for me, to try out some ideas I want to include in my talk about Windsor at KGD.NET meeting later this month.

Scenario

We have a messaging application built around two interfaces:

public interface Command

{

}

public interface Handler

{

    void Execute();

}

public interface Handler<T> : Handler where T : Command

{

    T Command { get; set; }

}

Hopefully I don’t have to explain how they work. The idea is, application receives commands from somewhere, then it pulls all handlers registered for this command and let them handle the command. Split of Handler interface into generic and non-generic part is there to make up for lack of co/contra-variance in .NET 3.5.

Commands and Handlers

Handlers are quite simple classes implementing closed version of Handler<> interface. For example to change client’s address we’d have the following command

[Serializable]

public class UpdateClientCorrespondenceAddressCommand : Command

{

    private readonly AddressDto address;

    private readonly Guid clientId;

    public UpdateClientCorrespondenceAddressCommand(Guid clientId, AddressDto address)

    {

        this.clientId = clientId;

        this.address = address;

    }

    public AddressDto Address

    {

        get { return address; }

    }

    public Guid ClientId

    {

        get { return clientId; }

    }

}

and its handler:

public class UpdateClientCorrespondenceAddressHandler : Handler<UpdateClientCorrespondenceAddressCommand>

{

    private readonly Repository<Client> clientRepository;

    public UpdateClientCorrespondenceAddressHandler(Repository<Client> clientRepository)

    {

        this.clientRepository = clientRepository;

    }

    public UpdateClientCorrespondenceAddressCommand Command { get; set; }

    public void Execute()

    {

        var command = Command;

        if (command == null) return;

        var client = clientRepository.Get(command.ClientId);

        client.ChangeCorrespondenceAddress(command.Address);

        clientRepository.Update(client);

    }

}

Nothing earth shattering here. We would have similar set up for other business events in the application. We assume we can have more than one handler for single command (for example another handler would update shipping costs and promotions available for the new address of the client).

The ability to pull multiple services from the container via typed factory is not available in Windsor 2.1.1 – you need the trunk version to take advantage of it.

Registration

To register the code we create an installer:

public class Installer : IWindsorInstaller

{

    public void Install(IWindsorContainer container, IConfigurationStore store)

    {

        container.AddFacility<TypedFactoryFacility>()

            .Register(

                Component.For<ITypedFactoryComponentSelector>().ImplementedBy<HandlerSelector>(),

                Component.For<AutoReleaseHandlerInterceptor>(),

                AllTypes.FromAssemblyContaining<Program>()

                    .BasedOn(typeof(Repository<>))

                    .WithService.Base()

                    .Configure(c => c.LifeStyle.Singleton)

                    .BasedOn(typeof(Handler<>))

                    .WithService.Base()

                    .Configure(c => c.LifeStyle.Is(LifestyleType.Transient)

                                        .Interceptors<AutoReleaseHandlerInterceptor>()),

                Component.For<HandlerFactory>().AsFactory());

    }

}

There are a couple interesting things here. First we register typed factory facility, which we’ll use later on to pull handlers for commands we receive. Then we register custom selector for typed factory (discussed below), and an interceptor (discussed below). Then we register all repositories and all handlers from given assembly, configuring handlers with transient lifestyle and with the interceptor we registered above. Lastly we also register typed factory for handlers:

public interface HandlerFactory

{

    Handler[] GetHandlersForCommand(Command command);

}

Typed factory selector

The handler factory has to do quite a lot of work for us. Given an instance of a command, it has to pull from the container all the handlers for the command’s type. To do this we need to use a custom selector (and trunk version of Windsor).

public class HandlerSelector:ITypedFactoryComponentSelector

{

    public TypedFactoryComponent SelectComponent(MethodInfo method, Type type, object[] arguments)

    {

        Debug.Assert(arguments.Length == 1);

        var message = arguments[0];

        var handlerType = typeof(Handler<>).MakeGenericType(message.GetType());

        return new TypedFactoryComponentCollection(handlerType.MakeArrayType(), new Arguments(arguments));

    }

}

Based on the command’s type we create closed Handler<> type and return TypedFactoryComponentCollection (new type that pulls all components for given service) passing down the command as typed argument to the resolution.

Putting it all together

We can now use the code like this:

private static void Main()

{

    using(var container = new WindsorContainer().Install(new Installer()))

    {

        var factory = container.Resolve<HandlerFactory>();

        DoActualWork(factory);

        Console.ReadKey(true);

    }

}

private static void DoActualWork(HandlerFactory factory)

{

    var command = ImmitateCommandArrived();

    var handlers = factory.GetHandlersForCommand(command);

    foreach (var handler in handlers)

    {

        handler.Execute();

    }

}

private static Command ImmitateCommandArrived()

{

    return new UpdateClientCorrespondenceAddressCommand(Guid.NewGuid(), GetSomeAddress());

}

Notice how simple the calling code is. It has no knowledge of the (quite complex) process that takes place behind the scenes to create strongly typed instances of appropriate classes. It does not even know what actual type of command it got.

What about releasing transient handlers?

Isn’t this code too simple though? It resolves handlers, which are transient components and it does not release them. And we all know transient components need to be released in Windsor, right?

Well – it does release them actually, it just doesn’t do it explicitly. Remember we registered an interceptor with all handlers. Here’s how that interceptor looks like:

[Transient]

public class AutoReleaseHandlerInterceptor : IInterceptor

{

    private static readonly MethodInfo Execute = typeof(Handler).GetMethod("Execute");

    private readonly IKernel kernel;

    public AutoReleaseHandlerInterceptor(IKernel kernel)

    {

        this.kernel = kernel;

    }

    public void Intercept(IInvocation invocation)

    {

        if(invocation.Method!=Execute)

        {

            invocation.Proceed();

            return;

        }

        try

        {

            invocation.Proceed();

        }

        finally

        {

            kernel.ReleaseComponent(invocation.Proxy);

        }

    }

}

The interceptor releases the component after the call to Execute for us. Thanks to this we take the burden (no pun intended) of releasing the components from the callers, and we make sure our handlers won’t leak memory. This is quite a useful trick actually, and while I have precisely zero knowledge of NServiceBus, I think it could be used to fix the issue Davy discussed, without having to mess with release policy.

Zen Coding and ReSharper PowerToys

Hadi Hariri — Thu, 11 Mar 2010 11:25:00 GMT

Yesterday the ReSharper Twitter Account tweeted about a Zen Coding Plug-in available as a PowerToy. If you’re not familiar with Zen Coding, check out this link. I received a couple of emails from people asking about the PowerToys and what exactly they were, and to be honest, I wasn’t really surprised. I don’t think many have actually heard of them. So I decided to follow Hanselman’s advice of minimizing key strokes, thus the post.

What are they?

The Power Toys are a series of plug-ins that have been written by the ReSharper developer team, and have been used in fact internally as samples of ReSharper’s API.

Where can I get them and how do I install them?

You can download the PowerToys for ReSharper 5 from the Early Access Program page (for previous versions, see What next?), which is here.

Unless there’s some API change, there are normally compatible from one build to the next, but just to be safe, download the one corresponding to the nightly build you have.

They are packaged up in a zip file that contains MSI installers for each individual plug-in, as well as a PowerToys Pack which includes them all (and you can pick and choose which one you want during the installation process). Best option is to just pick the full pack. Each MSI is also suffixed with a version, 8 corresponding to Visual Studio 2005, 9 to 2008 and 10 to 2010.

The zip file also contains another zip with the source code, which you can compile and install, if you don’t want to use an installer. If you’re doing this, compile them and place them under the %Program files%\JetBrains\ReSharper\Bin\Plugins folder. Normally best to create a folder for each plug-in (If you’re just interested in having the source but prefer to use the MSI, the installer will also install the source for you).

Once you install them, they should appear as plug-ins under the ReSharper menu:

As you can see from the list, there are quite a few goodies in there, not only Zen Coding!

What next?

The PowerToys are not only valuable in terms of the functionality they provide, but also serve as an example of how to write ReSharper plug-ins and interact with the ReSharper API, but they’ve never been released passed Early Access Programs. That is one reason 4.5 PowerToys are not available.

However, we want to change that. We not only want to make them available, but also to document them and offer them as a true OSS project, where the developer community can contribute to them, be it with additional features, bug fixes or providing completely new plug-ins.

This is something that I personally think would be valuable for the community. If you like this idea or have other suggestions, please feel free to give me feedback.

Sharing Code Analysis files between projects in Visual Studio 2010

Derik Whittaker — Wed, 10 Mar 2010 11:13:43 GMT

The ability to have static code analysis (aka run FXCop inside the IDE) is not something that is new to Visual Studio 2010. What is new is the simplicity in which you can share the exact same configuration across all of your projects at once.

Prior to VS2010 if you wanted to share your config it was not possible (from what I have ever seen). With VS2008 each .proj file contained a section in the file which laid out each rule that should/should not be turned on. If you wanted to share these what you needed to do was open up each .proj file in a text editor and copy/paste the rules. As you could image, copy and pasting this could get old real fast. In fact I would even argue that I may even prevent you from wanted to use the built in analysis all together.

Here comes Visual Studio 2010 to the rescue. In 2010 you can save your rules to a .ruleset file and you can import this same file into all your projects. No more need for copy/paste by hand.

Steps To Do This:

Step 1: Open up the Code Analysis tab in the project properties.

Step 2: In the drop down choose Browse

Step 3: Find your .ruleset file on disk

Step 4: Rinse and Repeat for all your other projects.

Now that having the ability to share your rule set across projects is painless you have NO excuse not to utilize this feature.

Till next time,

Help Save King’s Quest!

Rob Eisenberg — Wed, 10 Mar 2010 01:43:00 GMT

On February 28, 2010, Activision issued a Cease and Desist order against Phoenix Online Studios, creators of “The Silver Lining,” an unofficial sequel to the King's Quest series The sequel had, in 2005, been approved for non-commercial release by the owner of the King’s Quest IP, Vivendi Universal. The team has been working on the 5-part episodic King’s Quest Sequel for eight years (they started before 2005). They had just completed their final milestone and were preparing to submit the game for approval to Vivendi Universal right before Activision and Vivendi merged. Immediately upon acquisition of the King’s Quest IP, Activision shut down Phoenix Studios, with no intent to uphold the previous agreements.

As a long time fan of adventure games, and someone who has always wanted a real sequel to KQ6, I am really saddened by this. Personally, I plan not to have anything to do with Activision until they make this right. I hope you will join me in this. If you have a few minutes, please sign the online petition and consider sending a letter to Activision. Resources are below. Thank you. Now, on with your regularly scheduled programming…

Online Petition:
http://www.petitionspot.com/petitions/savetsl/
Facebook Group:
http://www.facebook.com/group.php?gid=382202612795&ref=mf
MySpace Page:
http://www.myspace.com/savetsl
Form Letter for Contacting Activision:
http://www.tsl-game.com/forum/index.php?topic=8406.0

[ANN] Chicago ALT.NET shows Rake and Albacore

sergiopereira — Tue, 09 Mar 2010 23:35:00 GMT

I haven't mentioned our meetings here in a while but our group has been going strong and enthusiastic all this time.

Tomorrow, March 10^th our topic will be build scripts for .Net projects using Rake and Albacore. I've been using Rake and a little bit of Albacore in my own projects and I'm ready to say that it will take a very serious event to make me go back to NAnt or MSBuild.

Introduction to Rake with Albacore.NET

6:00 pm
Pizza and networking time

6:30 pm

How would you to write your build scripts using a scripting language instead of XML? In this month's meeting we will see how the ease of programming in Ruby can be used to create a much more pleasant and extensible build script.

Rake isn't just for Rubyists or Alphageeks anymore. Albacore helps bring the power and expresiveness of the Ruby language to the world of .NET build automation. Using Rake it's never been easier to handle build automation, test execution, continuous integration and just about any task you need to automate for your build.

Michael D. Hall has been developing software on the Microsoft platform for over a decade. He's been an Alt.NETter for years and is really enjoying the exposure to different ideas and concepts beyond the safe confines of the .NET world. Currently he's a consultant working with Obtiva and has started a Cloud Developer's Group that meets monthly in McHenry county.

Silverlight Challenge: Creating a DependencyProperty

Christopher Bennage — Tue, 09 Mar 2010 20:36:39 GMT

The following code throws an exception. Can you spot the bug?

public class MyControl : Control
{
    public static DependencyProperty MyPropertyProperty = DependencyProperty.Register(
        "MyProperty",
        typeof (double),
        typeof (MyControl),
        new PropertyMetadata(0));

    public double MyProperty
    {
        get { return (double) GetValue(MyPropertyProperty); }
        set { SetValue(MyPropertyProperty, value); }
    }
}

Profiling Apps 1 of N: The MVC ActionLink

Hadi Hariri — Tue, 09 Mar 2010 20:34:00 GMT

I’m starting a new series of blogs posts on profiling, where we’ll try and cover common bottlenecks and how to identify them in your applications. However, before delving deeper into the subject, let me make a small but important observation:

Your bottleneck is probably not your for loop

Now, replace that for loop with switch statement, an older version of some outdated algorithm that you feel needs optimizing, or that retched collection of classes that would perform better if you were using an array to loop through them, and you’ll end up with the same observation.

Premature Optimization

When dealing with business applications, it is unusual for major performance problems to be pinpointed down to specific portions of code or a concrete implementation of an algorithm. Usually most of the issues are bottlenecks at the data level, network level or purely down to how a business decision is made.

Whether we use an ORM or use SQL directly, incorrectly formulated queries are one of the most predominant causes of bad performance. Not understanding concepts such as Lazy or Eager loading when using an ORM can be disastrous to the performance of an application, and are usually portrayed as “ORM XYZ sucks at performance”.

Network bandwidth and latency are other issues; when dealing with web applications for instance, having large pages (i.e. ViewState) or rendering Javascript directly without using script files, are a common problem for performance penalties. Making heavy calls to the server when very little information is required (i.e. UpdatePanel used incorrectly) are again main causes for concern.

In many cases, design decisions we make early can affect the performance of our applications, and it is important to identify these concerns and address them correctly. Using an ORM, profiling it, understanding how Ajax really works and not worrying about working with Javascript, or using an asynchronous architecture when dealing with long running business processes are many ways to avoid bad performance in the long run.

On the other hand, what we shouldn’t do is focus on micro-optimizations, on trying to make the most efficient, yet completely undecipherable algorithm to calculate the probability of winning money when buying lottery tickets, when the underlying problem is a bottleneck caused by a bad query. This kind of approach is often referred to as Premature Optimization, and can be disastrous for a project.

When it does boil down to code

Having said all that, there are times when we need better performance after having eliminated all the obvious causes, and need to discover why something is not performing as well as it should be. Of course, these concerns are greater when the nature of our application demands highly optimized code. In these cases, it is crucial to understand how things work in order to solve the problem. As a old-school boy, before we had managed libraries and drag-n-drop, I’m also a firm believer that it is always important to understand how things work under the covers, even if it is to just improve one self's knowledge.

Therefore, in these series of blog posts about performance, I’m going to focus on the latter, examining the details of code and how some things can perform better than others. So given the disclaimer, let’s get down to business.

In order to do performance tuning, you need to use a tool. Setting stopwatches doesn’t work, because as Christian Gross so rightly pointed out during one of his talks, and I semi-quote: ‘if you’re using a stopwatch, you think you know where the bottleneck is. Most of the time, you’re wrong’. If you are setting using a manual approach of setting calling Start and Stop, trying to time something, you’re assuming you know that the performance problem is located in a particular point, and many times it is not that point. So you end up having to place these kind of diagnostic codes in various places in your code, and soon it becomes a maintenance nightmare. Fortunately, there are tools that can profile your application in a non-invasive manner. When talking about SQL profiling, there’s NHProfiler for instance. When it comes to code performance profiling, the two most known ones are ANT Profiler and dotTrace. I’m going to be using dotTrace. I used it before joining JetBrains and continue to use it now that I’m at JetBrains. I’ll be using version 4.0 which is currently (at the time of writing this post), in Early Access Program and with Beta being released very soon.

To Express or not Express

Those that are familiar with it ASP.NET MVC know it relies heavily on the use of strings in many areas. For instance, when defining ActionLinks, you write

Html.ActionLink(“Home”, “Index”, “Home”)

where the first parameter is the link text, the second the Action and the third parameter is the Controller. The problem with this of course is that if you type either the second or third parameter incorrectly, you won’t know until runtime. Even if you build your views it won’t help.

An alternative is to use Expression based Html Helpers (another option is to use ReSharper of course :)). These are strongly-typed ActionLinks that do not ship out of the box with ASP.NET MVC, but are available as a separate download in the MVC Futures assembly, which can be thought of as a kind of sandbox for Microsoft to play with. Some of the functionalities in this library have eventually made it to the main core, such as RenderPartial, which was in fact there from pretty much the early Previews of MVC 1, and didn’t get all the excitement until it made it into the core in version 2. Other functionality, including the expression based ActionLinks haven’t made it in yet. When using these helpers, the previous link would be:

Html.ActionLink<HomeController>( a => a.Index, “Home”)

In principle this looks good, and begs the question of why it is not in the main core. Well I don’t know the exact reason, but one could potentially be due to it’s performance. Several people have talked about the difference in terms of rendering when using this version as opposed to the standard string based one. You can find one of those posts here. What I thought I’d do, is actually see how much difference in speed there is between one and the other.

The Project

I’m using a very simple project for this profiling. It’s your standard ASP.NET MVC 2 application. On Index page, I’ve added two blocks of code:

 <% for (int i = 0; i < 1000; i++)
{%>
  <%= Html.ActionLink("Link " + i, "Index", "Home")%><br />
  <%
} %>
 
<% for (int i = 0; i < 1000; i++)
{%>
  <%= Html.ActionLink<HomeController>(a => a.Index(), "Link " + i)%><br />
  <%
} %>
 

The first for loop will render out 1000 links using the string based ActionLink version, whereas the second loop will do the same using the expression-based one.

What we want to do now is run this and see how long it takes for each loop to complete.

Setting up dotTrace Profiler

Working with dotTrace is as easy as it gets. There are two ways to profile an application: Standalone or integrated within Visual Studio. In the case of the former, you can start up dotTrace outside of Visual Studio and point to an application to profile. On the other hand if you have it integrated inside Visual Studio, then all you need to do is click on the Profile menu option:

Once we do that, we get a dialog box that provides us a series of options, mainly to do with the type of profiling we are going to perform.

Since we’re profiling a web application, we can either use the Development Server or Internet Information Server. In our case we’re going to use the former. dotTrace will automatically pick up the server settings as well as fill out the physical path for our application.

Next come the profiling options. The basic settings are Profiling Type and Meter Kind. The first parameter indicates how profiling will take place. It can be:

Sampling: dotTrace will do frequent analysis of calls stacks. It’s the least intrusive, has very little impact on performance, but gives approximate timing.
Tracing: dotTrace receives notifications from the CLR on entry/exit of methods. More precise timing and call information.
Line-by-Line: dotTrace logs times for every statement in methods. Most precise but also has higher impact on performance.

Tracing is normally the recommended option. Meter Kind defines how dotTrace logs the time: CPU instruction or Performance counter (uses the Windows API and samples are hardware independent).

Profiling our application

Once we have everything setup, we can start profiling our app. dotTrace will launch a small panel that allows us to control data sampling.

dotTrace does not by default however launch the browser. In order to do so, we need to either click on the WebDev server and Open in Browser or just type the URL directly in the browser.

The next step is to perform the operations we want to profile and then click on GetSnapshot.

Since in our case, having rendered the Index action performs these operations, once the page has been loaded, we can click on GetSnapshot and have the profiler launched.

I’m not going to get into all of the details of dotTrace in this first post because otherwise it would never end; we’ll cover some of the aspects in future posts. For now, lets focus on our performance test at hand which is the difference between the two types of ActionLinks (string and expression based).

The easiest way to find what we are looking for is to use the…you guessed it, Find feature. Ctrl+F will bring up a dialog box similar to ReSharper’s Type location. We can then type ActionLink to filter the list of functions down to the ones that interest us

We can see that there are two versions, as expected. Let’s drill in to the second one first, the string based one. Hitting Enter will find the first location. We can then press F3 until we find the one that interests us. Remember, Site.Master and other references to this call also exist. We’re specifically looking for the loop, the one with 1000 calls

We can see that the ActionLink call takes 121ms for 1000 calls. Drilling in, we can see exactly where the time is spent, and 104ms of that is calling GenerateUrl. Now let’s take a look at the Expression based ActionLink

For the same 1000 calls it takes 140ms, which is an increase of approximately 17%. Diving in once again, we can see that 6ms of this is in the parsing of the expression tree, GetRouteValuesFromExpression. What this function does is merely analyze the expression to extract the ActionName from the parameter. The ControllerName it already has since it’s the concrete type the generic method is invoked with, returning both values in a RouteValueDictionary. As such it then needs to call GenerateRouteLink as opposed to GenerateLink since the former takes a RouteValueDictionary as a parameter, whereas the latter takes strings indicating the controller and action. They ultimately both call GenerateUrl.

Summary

From the results, the difference between the two calls is not that significant for 1000 links. As the number of links increment, the difference between the two does not change significantly. For instance, rendering 10.000 links, has a difference of 50ms between one version and another. What’s interesting that having run the same profiling on previous releases, the difference in time was nearly double, so there seems to have been improvement in this area. And as we can see, sometimes what might seem a performance problem, isn't necessarily one.

Rule "Previous releases of Microsoft Visual Studio 2008" failed

sergiopereira — Sun, 07 Mar 2010 10:43:00 GMT

Today I was trying to install SQL 2008 on my box and the setup stopped after checking a bunch of rules. The error message was the title of this post.

A quick search on the internet revealed that somehow the installer didn't believe I had VS 2008 SP1 installed, which I did. The recommendations in the KB article were kind of insulting. There's no way I'd spend hours of my day uninstalling and reinstalling VS and SQL — sorry, no chance. I also could not accept not installing the Management Tools, for example. I also did not have any Express version of VS or SQL installed in this box.

A little snooping around with ProcMon led me to the following registry key:

HKLM\SOFTWARE\Wow6432Node\Microsoft\DevDiv\VS\Servicing\9.0\IDE\1033

In that key I noticed the suspicious values:

"SP"=dword:00000000
"SPIndex"=dword:00000000
"SPName"="RTM"

Without quitting the SQL server installer validaton screen, I changed these values to what you see below, crossed my fingers and rerun the installer validation, which passed!

"SP"=dword:00000001
"SPIndex"=dword:00000001
"SPName"="SP1"

Now, I didn't really guess those values. I looked in a sibling registry key (...Servicing\9.0\IDE\1033) and saw that it contained those new values, then I copied them.

I think I didn't break anything. So far all seems to be working. But, as usual with anything related to manual registry hacking, you have to be really insane to change your settings because you read on a random blog on the 'net. I'm just saying... Don't come crying if your house burns down because of this.

The Biggest Driver For Domain Modeling Decisions

Michael Nichols — Sun, 07 Mar 2010 06:45:00 GMT

I just read a post from fellow devlicio.us'er Billy McCafferty and was considering what influences my own solutions to these concerns (ie, repositories, data transfer, etc) now.

There has been an abrupt shift/growth in my thinking this year in how I perceive my domain and how I interact with or scale it. CQRS, perceived by some as a shiny new toy, and the discussions it provokes has definitely contributed to the maturity of the project I have been on by increasing its quality and adaptability. Why? My experience has been the simple shift to being concerned about what all these things are doing (behavioral mindset) instead of what they look like (stateful mindset). I now see that the decision to expose domain state at all should be one of the first decisions to make and its implications on the various infrastructural concerns should be well-understood. This seems to drive divers decisions both within the domain and how it is consumed or utilized without.

The first casualty of this shift was the getters and setters (whether exposed as properties or GetX()/SetX() methods). Hiding as much state as possible radically increases the freedom in the domain, especially when going down the event-sourcing route. As you know, the moment you expose a getter you now have a maintenance obligation. What I am discovering is that feels okay initially, but it very quickly acts as a Trojan Horse for forces outside the domain to act on its modeling. That innocent {get;} can make refactoring far more difficult that it needs to be, if only the decision were made earlier to Report state from somewhere other than the domain.

IMHO, this is true for a “small” application, although I am not sure I believe in “small” applications anymore. They all seem to be getting feature-creep hormones from somewhere :).

Providing Metadata to your MEF exports

Derik Whittaker — Sun, 07 Mar 2010 01:07:24 GMT

Many months ago I created a post on how to get started with MEF. Ever since then I have been meaning to get this post (and others) about about how to get up and running quickly with MEF.

In this post will demonstrate how to provide Metadata (custom values which can help provide context) information to your Exported item. Why should you care about Metedata? Below is a great reason from the MEF site on codeplex

Declaring Exports explained the basics of parts exporting services and values. In some cases it’s necessary to associate information with exports for a variety of reasons. Commonly it’s used to explain about the capabilities of an specific implementation of a common contract. This is useful to allow imports to either constraint the export that can satisfy it, or to import all available implementations at the time and check their capabilities in runtime before using the export.

Before we get rolling:

What I am going to show in this post is how to create a custom Export Attribute. It is possible to expose Meta via the build in ExportAttribute, but the built in mechanism has a few short comings:

Not discoverable
Not strongly typed
Compiler cannot validate the data content

Lets get rolling:

Pre-Step 1: Taking a look at the Class which we will mark as a Export

    public interface IPlugin
    {
        string PluginAction();
    }

    [Export(typeof(IPlugin))]
    public class DefaultPlugin : IPlugin 
    {
        public string PluginAction()
        {
            return "This is the default plugin";
        }
    }

Step 1: Defining the interface which will represent your

In order to create discoverable Metadata you will first want to create an interface which will represent your metadata. Below is my interface.

    public interface IPluginMetaData
    {
        string Name { get; }
        string Version { get; } 
    }

We will later use this interface when we define and use our custom Export Attribute. The main reason for creating this attribute is now the compiler has a hard wired way to know exactly what type of data is being exposed in your Metadaa

Step 2: Defining your custom ExportAttribute Attribute

Now that we created our interface to give us strong typing and discoverability we need to create a custom attribute which will allows the MEF engine to know we have Metadata to expose

    [MetadataAttribute]
    [AttributeUsage(AttributeTargets.Class, AllowMultiple = false)]
    public class PluginMetadataAttribute : ExportAttribute
    {
        public PluginMetadataAttribute( string name, string version)
            : base(typeof(IPluginMetaData))
        {
            Name = name;
            Version = version;
        }

        public string Name { get; set; }
        public string Version { get; set; }
    }

When looking at the code above there are 3 things to pay close attention to

You need to make a call into the base constructor of the ExportAttribute and provide it the type of your interface which defines your Metadata
You need to mark your attribute with the [MetadataAttribute] (which is part of MEF)
You need to mark the usage type of your attribute. I am not 100% why this is needed (Glenn, you out there with an answer???)

Step 3: Providing your Metdata to your Exported Class

    [Export(typeof(IPlugin))]
    [PluginMetadata("Default", "1.0.0.0")]
    public class DefaultPlugin : IPlugin 
    {
        public string PluginAction()
        {
            return "This is the default plugin";
        }
    }

The code above is the same as the code we saw in pre-step 1, but this time we have marked the class with our custom Metadata attribute. We have now officially provided our Metadata to our Export…. But how do we get this information out of MEF?

Step 4: Setting up your [ImportMany] to use the Metadata

If you are using an ImportMany (this should also work on an Import, but I have never tried) most likely you are pushing your Exports into a IList or IEnumerable. If this is the case, your changes are pretty minor. Below is what you need to do in order to have your Metadata loaded.

[ImportMany(typeof(IPlugin), AllowRecomposition = true)]
private IList<Lazy<IPlugin, IPluginMetaData>> _loadedIPlugins = new List<Lazy<IPlugin, IPluginMetaData>>();

If you have not seen the Lazy keyword, you are not alone. This is new to .Net 4 and this provides Lazy initialization support to the framework. (part of the System namespace). One key thing to understand here though is that the Lazy keyword out the box is only Lazy<T>, but the Lazy we are using is Lazy<T, M>. This extended version of Lazy lives in the MEF assemblies (System.ComponentModel.Composition) and will need to be referenced to use.

Step 5: Using the Metadata

Once you have the Export loaded into your container (which by the way does not need to change to have this work) you can access your container by selecting the .Metadata property on your instance of the export. The image below shows it in action.

As you can see, exposing and using Metadata via MEF is a snap.

Till next time,

A Few Thoughts on DDD, DTOs, View Models, Repositories and Separation of Concerns

Billy McCafferty — Sat, 06 Mar 2010 16:41:00 GMT

What I've loved most about developing an open-source project is the ideas that I get from others who look at the work and either A) validate ideas, B) suggest that something stinks, or C) call a royal WTF and force people (e.g., me) to explain ideas more fully. It's usually during these explanation attempts that light bulbs start to come on and ideas are refactored and become more substantiated (or at least more defendable). The S#arp Architecture forums have been a gold mine, IMO, for the discussion of the practical application of balanced DDD techniques on real-world projects. After feedback that I've already gotten on my recent post concerning application services and CQS and listening to and adding my two cents concerning ideas on the S#arp forums, I'd like to share a few ideas (that I shared on the forum) concerning drawing the line among application layers, the management of DTOs and View Models, and a general discussion of separation of concerns. (As Chris Carter correctly (and a tad bluntly) explained, don't take these ideas at face value...use them as a point of discussion and contemplation to come to your own conclusions with your project team...and let me know what you think.)

Every great developer knows that any problem can be solved by adding another layer of abstraction. ;)

Obviously, with additional layers of abstraction and indirection, we also introduce complexity and additional objects which need to be maintained. Over the past year, I have had struggles concerning just how far the "DTO paradigm" should be taken to effectively separate layers from the domain and "best practices" for how they should be used. I don't think the answer can be found in a best practice (but I also hate to leave it simply at "it depends"). I truly feel that the most important practice is for a project development team to decide, and firmly agree upon, which approach will be taken on a project and for the agreed upon approach to be followed with discipline (and enforced via code reviews) by the team.

On a couple of recent projects, the biggest problems we ran into weren't concerning which approach to leveraging DTO for layer separation was "best," but on coming to a firm layering decision and having the team discipline to adhere to those practices. Because of these "gray" areas, which we didn't come to a firm team agreement on, there were inconsistent practices used by the developers which led to rot, particularly between the controller (or code-behind) and application services layer.

So while we can discuss which approach is best or most effective, I think the greater concern is for the team to pick a direction, to stick to it, and to diverge or refactor as a team decision.

But as I said, I don't want to leave it at "it depends." ;) So after reading everyone's ideas here and contemplating further on past projects and the ideas I recently put forth in http://devlicio.us/blogs/billy_mccafferty/archive/2010/03/05/better-application-services-and-cqs-with-s-arp-architecture-1-0-q3-2009.aspx, here are a couple of ideas that I've been trying to adhere to (and/or will be adhering to on my next project). The layers referenced below may be viewed in a package diagram here for better clarity of what's discussed.

Usually, one object should be used to populate a form while a second should be used to collect data from a form. The former would contain information for default/selected values along with drop-down values, for examples, while the latter would encapsulate which options were selected when the user submitted the form. Personally, I use a <EnityName>FormViewModel to populate the form and use an entity to collect from the form...but I see it equally valid to instead use an intermediary DTO to collect from the form if further separation is warranted. Additionally, I feel it is OK for a FormViewModel object to have references to domain objects to make it easier to transfer data to the form for input population. This is an arguable point and would be just as valid to only pass DTOs in the view model for a cleaner separation between view and domain, with the acceptance that there will be more objects and maintenance that comes with that approach.
I believe that view models should be maintained either in the application services layer OR in a separate ViewModels class library if a project team feels the additional separation is warranted (although I can't envision much reason to do so). (I'll be modifying my sample project post to reflect the former.) Either way, they should not be maintained in .Core to keep a very clean separation from domain concerns. While the name "ViewModel" implies that they are a view concern, they only describe what should be displayed, not how it should be displayed. Accordingly, there is still a very clear separation of concerns between the view layer (which the user interacts with) and the view model classes. Furthermore, the application services expose methods which should be usable by any type of client. In line with this, a ViewModel or FormViewModel class does not impart a particular mechanism for the implementation of the view layer - again, it only describes what data should be available to the view. So even if view model classes are maintained in app services, this does not preclude there use by various client types; e.g., they could be equally consumed by ASP.NET, ASP.NET MVC, Spark, SilverLight, etc. (The only caveat is that if the view model classes maintain references to domain objects, then it will be more difficult to expose them for serialization via web services and WCF. Accordingly, a project team should firmly decide if ViewModels may contain references to domain objects.)
I believe that DTOs should be maintained in a separate assembly and have no reference to .Core or be maintained in .Core if warranted with the acceptance of decreased "shareability." DTOs should almost always be serializable; i.e., transferable via web services and WCF. This allows the DTOs class library to be easily shared with a consumer of web services which may expose these objects, for easier deserialization. Some of the motivations for deciding when to use DTOs would be to provide a clean separation between the view and app services (if a project team feels its warranted), to expose data to web service consumers, and to better enable Command/Query Separation.
Repositories may return Entities, Value Objects or DTOs, in addition to other "basic" types; e.g., primitives, arrays, etc. Ideally, repositories would not be used by domain objects (even via their interfaces) and would have their interfaces maintained in the application services layer. If the repository interfaces are maintained in .Core, then this forces DTOs to be maintained in .Core as well with the possibility that domain references may "leak" into DTOs. If the repository interfaces are maintained in .ApplicationServices, then DTOs may be maintained in a cleanly separated library without worrying about the line between DTOs and domain objects being grayed. But data interfaces (and DTOs) may be maintained in .Core if the team feels the simplification is warranted.

With all this said, I still think the most important decision is deciding a path to take for your project, having the project team agree upon it, and maintaining the discipline to stay on course.

Your feedback on these ideas is most welcome!

Billy McCafferty

Better Application Services and CQS using S#arp Architecture 1.0 Q3 2009

Billy McCafferty — Fri, 05 Mar 2010 18:47:00 GMT

Updated 2010.03.09 to reflect small modifications that were decided through subsequent discussions on S#arp forum and other DDD posts.

Obviously, S#arp Architecture is the bee's knees when it comes to developing ASP.NET MVC applications. ;) But as a project evolves and gets larger, "out of the box" S#arp Architecture 1.0 guidance runs into a few pain points. Particularly, there's poor use of the application services layer, the separation between controllers and application services is not very clear, entity listing pages become performance bottlenecks as the domain model gets sizable, there is no command/query separation (CQS) "out of the box", and unit tests require re-occurring maintenance to deal with changes in the number of constructor parameters to controllers and application services. While the amicable and adroit Alec Whittington (who is taking over the lead role from me on S#arp Architecture) is hard at work upgrading S#arp Architecture to accommodate recent dependency upgrades and accommodating ASP.NET MVC 2, I wanted to take a stab at resolving some of the architectural issues that I've run into, on S#arp projects over the past year.

I've developed and included a sample project, built on S#arp Architecture 1.0 Q3 2009, for the following key reasons:

To resolve some "pain points" that develop as S#arp projects grow to large sizes,
To demonstrate better use of the application services layer,
To demonstrate better command/query separation of the entity listing pages for dramatically better performance as the domain model grows,
To create an architectural spike for a new project I'm working on, and
To collect feedback from the S#arp community to determine if this is an appropriate architectural direction for the next release of S#arp Architecture.

Please post any feedback and/or suggestions you may have in the comments below or, more preferably, to the S#arp Architecture forums at http://groups.google.com/group/sharp-architecture.

Setup instructions

Unzip the sample project to a BetterAppServices folder
Create a new database called BetterAppServices
Using SQL Enterprise Manager, run:
1. /BetterAppServices/db/Schema/CreateBetterAppServicesDb_ChangesWillBeLost.sql
2. /BetterAppServices/db/StoredProcedures/CreateGetProductCategorySummaries.sql
3. /BetterAppServices/db/StoredProcedures/CreateGetProductSummaries.sql
Open /BetterAppServices/BetterAppServices.sln with VS 2008
In VS 2008, open BetterAppServices.Web/NHibernate.config and change the connection string to point to your BetterAppServices database
Right click the BetterAppServices.Web project and "Set as StartUp Project"
Run (F5) the project to see everything in action.

Changes from "out of the box" S#arp Architecture 1.0 Projects

This project is more of an architectural spike more than anything else at the moment. Accordingly, the CRUD scaffolding generator has been removed and non-essential unit tests have been removed to focus on the architecture itself. Many of the changes will be incorporated into the S#arp CRUD scaffolding generator; this will either be available in the next release, or will be provided as an add-on, as this new approach does add complexity and introduces a major breaking change to existing 1.0 projects.

Major changes include:

/db Folder Changes
- Added /db/Schema/CreateBetterAppServicesDb_ChangesWillBeLost.sql. This gets auto-regenerated when unit tests are run. The motivation was to have the DB schema automatically maintained while developing.
- Added /db/StoredProcedures/CreateGetEntityNamePluralSummaries.sql. These SPs provide command/query separation for the entity listing (Index.aspx) pages, which frequently became a performance bottleneck.
Cross-Project Changes
- Moved /BetterAppServices.Core/DataInterfaces/* to /BetterAppServices.ApplicationServices/DataInterfaces/. This is the only major, possible breaking change for existing applications. This was done to further remove the potential of domain objects using data repositories directly, and to allow the repositories to return objects from a new Dtos project for command/query separation, among other benefits (dicussed below). Decided not to do this to support domain services which may require the use of repositories and to make upgrading from previous version much simpler in some cases. Having the interfaces in .Core doesn't necessitate that domain objects use them; in fact, my rule of thumb is for all domain objects to avoid the use of repositories unless an exceptive case exists.
- Replaced all uses of "using BetterAppServices.Core.DataInterfaces;" to "using BetterAppServices.ApplicationServices.DataInterfaces;" to support the above mentioned change.
- Replaced all uses of IRepositoryEntityName with IEntityNameRepository. Be default, all entities now have an explicit repository. This avoids the need to manually change from the generic to the explicit, when the need arose, in unit tests and in constructors; which was frequently occurring.
/BetterAppServices.Core/QueryDtos (/BetterAppServices.Dtos)
- Added a Dtos class library to provide an appropriate location for View Models and DTOs. While this project currently has a dependency on BetterAppServices.Core, so that the View Models can contain references to domain objects, this dependency could be severed for better separation between the view and the domain. The caveat is that much more work would be required maintaining a more complete DTO layer and transferring data via DTOs in all of the CRUD pages. Decided that a separate assembly was overkill. Consequently, added this namespace to contain query DTOs for transferring results of "report" queries into objects. With this example project, only the listing page uses "pure" DTOs for much better performance. The other CRUD pages still communicate directly with domain objects to keep things much simpler. This is something that can be argued either way and it should depend on the project needs to determine if a more separated approach is warranted.
- Added EntityNameDto.cs to act as a summary object to be bound to results from stored procedures (e.g., the entity listing pages), or other DTO needs.
/BetterAppServices.ApplicationServices/ViewModels

Added this namespace and EntityNameFormViewModel.cs to hold data related to adding and updating the EntityName. This object gets populated and passed to the entity form pages, accordingly.

/BetterAppServices.ApplicationServices
- Added reference to BetterAppServices.Dtos so that app services can return DTOs.
- Added EntityNameManagementService.cs. This app service class removes the CRUD logic from the controllers, makes the logic more reusable, and creates an appropriate class to add additional application service logic to.
- Added IEntityNameManagementService.cs. This app service interface makes unit testing more maintainable because you can mock the service interface and not worry about when the concrete class' constructor arguments change.
- Added /DataInterfaces/IEntityNameRepository.cs. As described above, every entity now has an explicit repository interface to avoid changes down the road when custom interfaces would inevitably be introduced.
/BetterAppServices.Data
- Added /BetterAppServices.Data/EntityNameRepository.cs to implement the associated interface. An important thing to note is that method provided invokes a stored procedure to act as a reporting means in line with command/query separation. This is useful for entity listing pages which would frequently, previously, end up loading a huge portion of the domain model to show summary information.
- Added /BetterAppServices.Data/NamedQuery/GetEntityNameSummaries.hbm.xml and set its compile action to "Embedded Resource." This provides the "short cut" for invoking the stored procedure. It could easily be modified to accept paging parameters.
- Added reference to BetterAppServices.Dtos so that repositories can return DTOs for better command/query separation.
/BetterAppServices.Web
- Added reference to BetterAppServices.Dtos to be able show DTOs on web pages.
- Changed ComponentRegistrar.AddCustomRepositoriesTo "BetterAppServices.Core" to "BetterAppServices.ApplicationServices" to reflect the new location of the data repository interfaces.
/BetterAppServices.Web.Controllers
- Added reference to BetterAppServices.Dtos.
/BetterAppServices.Tests
- Modified MappingIntegrationTests.CanGenerateDatabaseSchema to save DB schema to /db/Schema/CreateBetterAppServicesDb_ChangesWillBeLost.sql every time the unit test is run.

To reiterate, many of the changes above can be incorporated into a CRUD scaffolding generator; the focus with this example project is on providing an archtectural spike of the proposed architectural revisions.

Even if you don't use S#arp Archtiecture, this sample project should serve as a good example of using application services and basic use of command/query separation (CQS). Although the CQS in the sample project could be taken much further, I felt that the sample provides a good balance between practical maintainability and a more austere separation of concerns.

Enjoy!

Billy McCafferty

1 Simple Step for Commanding in Silverlight

Christopher Bennage — Wed, 03 Mar 2010 16:24:00 GMT

Silverlight 4 is now supporting the commanding that we’ve come to love from WPF. Commanding was a foundational feature for MVVM. It’s what enabled us to bind to methods on our view models.

John Papa has an excellent introductory post on using commands in Silverlight 4. This pattern is called the DelegatingCommand pattern (or sometimes RelayingCommand).

I’d like to show you the Caliburn way of handling this. I’m going to steal John’s viewmodel from the aforementioned post (and hope he doesn’t sue).

The viewmodel presents a collection of all products and a filtered collection of products. You can modify the filter by calling LoadProducts().

public class ProductViewModel
{
    public ProductViewModel()
    {
        Products = new ObservableCollection<Product>();

        AllProducts = new ObservableCollection<Product>
                          {
                              new Product {ProductId = 1, ProductName = "Apple"},
                              new Product {ProductId = 2, ProductName = "Orange"},
                              new Product {ProductId = 3, ProductName = "Banana"},
                              new Product {ProductId = 4, ProductName = "Pear"},
                              new Product {ProductId = 5, ProductName = "Grape"},
                              new Product {ProductId = 6, ProductName = "Grapefruit"},
                              new Product {ProductId = 7, ProductName = "Strawberry"},
                              new Product {ProductId = 8, ProductName = "Melon"},
                              new Product {ProductId = 9, ProductName = "Guava"},
                              new Product {ProductId = 10, ProductName = "Kiwi"},
                              new Product {ProductId = 11, ProductName = "Pineapple"},
                              new Product {ProductId = 12, ProductName = "Mango"}
                          };
    }

    public ObservableCollection<Product> AllProducts { get; set; }

    public ObservableCollection<Product> Products { get; set; }

    public void LoadProducts(string filter)
    {
        Products.Clear();
        var query = from p in AllProducts
                    where p.ProductName.ToLower().StartsWith(filter.ToLower())
                    select p;
        foreach (var item in query)
        {
            Products.Add(item);
        }
    }

    public bool CanLoadProducts
    {
        get { return true; }
    }
}

Let me point out a few notable differences between John’s original and my version of the viewmodel.

There is no ICommand property.
CanLoadProducts is a property on my model, it was a method on the original

The snippet from the corresponding view would look like this:

<StackPanel>
    <TextBox x:Name="filter" />
    <Button x:Name="LoadProducts" Content="Load" />
</StackPanel>

The Explanation

It’s binding by convention, and it is a new feature of Caliburn added after the 1.1 release^[1]. So you’ll need to get the trunk to do this.

When you have a button named LoadProducts, Caliburn will look for a method on your viewmodel named LoadProducts and automagically handle the binding for you. In addition, it will check for either a method or property (as in this example) named CanLoadProducts that it will use to toggle the enable/disabled for the button. Also, since we have a parameter named “filter” on LoadProducts, Caliburn will check to see if there is an element in the view name “filter” and pull the value from that.

There’s a great deal more that you can do with conventions (and you can even plug in your own conventions).

This also works for Silverlight 3 and WPF.

You can also see an example of this in Ayende’s sample app Alexandria.

Actually, you can do some of this in 1.0, but it is easier and much richer in the trunk. Ping the forums if you have a need to use it in 1.x.

Around the World in 90 Days

Jak Charlton — Tue, 02 Mar 2010 06:38:00 GMT

Around 3 months ago, I packed up in the UK, and headed to the other side of the world, to Australia.

Last Autumn I was chatting to Richard Banks over Twitter, and he mentioned that Readify were looking to hire good .Net developers in Australia. I joked that if they wanted to pay my air fare over I would certainly do an interview.

Sadly Readify don't pay for the air fare, but after a bit more joking I took Richard seriously and dropped them a copy of my CV. A few months later, after a fairly thorough interview (part of which took place over Skype and Live Meeting... sadly the reason for no free holiday), I took the decision to join Readify as a Senior Consultant.

For the last 18 years I have been a self employed consultant / contractor in the UK, and have made a fairly good living at it. In fact this will be the first time I have been an employee since I was aged 22. So this was a fairly big decision.

What swung it for me was the general positive attitude of the Readify people I spoke to, and their focus on technical excellence and good development practices. This is a company that is rapidly growing, and despite the general world economic conditions, Australia managed to avoid the vast majority of the financial crisis.

As part of their expansion, Readify are still recruiting, and due to the shortage of good developers in Australia, they are willing to hire from overseas, and deal with all of the immigration and visa issues needed to get you into the country. So far at least one person I have chatted to over Twitter has applied, and if you look through the list of Readify employees you are likely to see a number of people who are highly respected in the .Net world - it's a great bunch of people.

Apparently only 1% of applicants to Readify get through the interview process, so if you are looking for a new career, are open to moving, and are pretty darn hot around .Net and good development practices, maybe you should think of applying. http://readify.net/about-readify/careers/

Message-Based Systems for Maintainable, Asynchronous Development

Billy McCafferty — Tue, 02 Mar 2010 04:22:00 GMT

Preface (you know it’s good if there's a preface)

In Architectural Paradigms of Robotic Control, a number of architectures were reviewed including deliberative, reactive, and hybrid architectures. Each of these exhibit a clean separation of concerns with layering and encapsulation of defined behaviors. When implemented, the various capabilities, such as planners and mobility controllers, are encapsulated into discrete components for better reusability and maintainability. A pivotal aspect not discussed in the previous article is how the various system layers and components communicate with each other, such as reporting sensor feedback and sending commands to actuator controllers. Effectively resolving this communication challenge is not only important to robotic systems but to many other industries and domains for the successful integration of disparate applications.

To give credit where credit is due, this article pulls quite heavily from the patterns, taxonomy, and best practices presented in Enterprise Integration Patterns (Hohpe, 2003). This well organized book is chock full of hard learned lessons and solid guidelines for developing maintainable message-based systems. This article should not be seen as an adequate replacement for that book (it’s more like cliff notes with a spackling of robotics bias); indeed, Enterprise Integration Patterns should have a prominent place on your bookshelf if you're developing message-based systems – so read this post and then browse http://www.eaipatterns.com/ while waiting for your copy to arrive to delve deeper.

A Need for Message-Based Systems

A few industries in particular, such as finance, healthcare and robotics, are demanding integration of an intimidating number of separate technologies that may be spread across computers, networks, and/or built upon a variety of technological platforms. Not only is this integration tricky, it can come with a significant cost to performance and maintainability if not implemented correctly. Accordingly, a solution is needed which facilitates loosely coupled integration while accommodating the performance demands of the task at hand. Taking a message-oriented approach to inter-application communications is one such way to accommodate these demands in a maintainable manner without sacrificing performance. This article gives an introduction to developing message-based systems using messaging middleware, describes taxonomy for discussing messaging topics and patterns, and includes a number of best practices.

Before delving further, it's important to clarify a few terms that will be used frequently:

Messaging Middleware (aka, a message bus): a 3rd party application which provides messaging infrastructure and capabilities (e.g., MSMQ, MS Concurrency and Coordination Runtime (CCR), Robot Operating System (ROS)),
Component: a stand-alone application or piece of executable code which communicates with the messaging middleware,
Message-based system: the entirety of the system including all integrated components and the messaging middleware.

As stated, messaging provides one means of facilitating inter-component communications. But as with any design approach, the project requirements must be carefully considered to determine if messaging is the appropriate mechanism for integration. While messaging is robust and facilitates integration, it also adds complexity and indirection. So before deciding to use messaging as the means of integration, consider all component integration options including (Hohpe, 2003):

File Transfer: wherein a component produces files of shared data which other components consume,
Shared Database: each component stores and retrieves data from a common database,
Remote Procedure Invocation: each component exposes specific procedures to be invoked remotely for exposing behavior and exchanging data,
Messaging: each component connects to a common messaging system, using messages to invoke behavior and exchange data.

Determining which integration approach is most suitable to your project's needs is beyond the scope of this article, focusing instead specifically on messaging. In turn, we'll review important elements of developing a message-based system including: message channels, messages, message routers, and message endpoints.

Message Channels

When a component sends information to another component in a message-based system, it adds the information to a message channel. The receiving component then retrieves the information from the message channel. Different channels are created for each kind of data to be carried; having a separate channel for each datatype better enables receiving components to know what kind of data will be retrieved from a given channel. For using a channel, each channel is addressable for sending and retrieving messages to/from them. How a channel is addressed varies depending on the messaging middleware being leveraged, but it's usually a port number or a unique string identifier. As a good practice for keeping channels organized, if string identifiers are available, a hierarchical naming convention may be employed to label channels by type and name; e.g., a channel carrying laser scans might be called "Perception/LaserScans."

There are two basic kinds of message channels:

Point-to-Point Channels (aka - client/server style): routes messages for components to talk directly with other components; e.g., a remote procedure call to another component. A message over a point-to-point channel only has a single receiver; so while the sender may not necessarily know who the receiver is, the sender can rest assured that the message will only be received by one receiver – it’s a FIFO queue.
Publish-Subscribe Channels (aka - broadcast): routes messages for components to publish data and an arbitrary number of components to subscribe to that data. A copy of the message is generated for each subscriber on the channel.

In addition to channels intended to carry information among components, it is a good practice to setup an invalid message channel that bad-formed or unreadable messages may be forwarded to for logging and to assist with debugging.

Messages

With a function call, a simple parameter or object reference may be passed and retrieved by the invoked method, sharing the same memory space. But when passing data between two processes with separate memory spaces, the data must be packaged into a "message" adhering to an agreed upon format which the receiver will be able to disassemble and understand. The sender of the message passes the message via a message channel. The receiver retrieves the message from the message channel and transforms the message into internal data structures appropriate for the task at hand.

A message is made up of two parts:

Header: describes the data being transmitted and details concerning the message itself; e.g., origin, timestamp information, message expiration (if content is time-sensitive), message identifier, correlation identifier, return address, etc., and
Body: the data content that the receiver is looking to use.

When sending a message, the sender intends for the message to be used, or responded to, in a particular way. The intention of the message may be described as being one of the following:

Command Message: invokes a procedure in another application,
Document Message: passes a set of data to another application,
Event Message: notifies another application of a change in state, and
Request-Reply: requests a reply from another application.

Event messages deserve a bit more discussion. In its simplest form, an event message would simply be informational, letting subscribers know that an event has occurred; e.g., a new laser scan is available. If subscribers would like details concerning the event, they would send a request-reply to the sender of the event to provide further details; e.g., the laser scan details. Alternatively, the event could be a document as an event to inform subscribers that an event has occurred along with the details of that event; e.g., a new laser scan is available with laser scan details included. The size of the event details and the rapidity in which the event occurs should be considered when deciding between publishing simple event messages and document messages as events.

Request-reply messages could also use a bit more describing. A request-reply is usually implemented as two point-to-point channels. The first channel delivers the request as a command message, while the second carries the reply back to the requestor as a document message. To keep the replying component more loosely coupled and reusable, the requestor should include a return address indicating the channel that the replier should use to publish the reply. After receiving the reply, a challenge for the requestor is to then correlate the reply to the original request. If the requestor is sending a number of requests in succession, it will likely be difficult to keep clear – if it matters – which request a reply is associated with. To resolve this, every request may include a unique message identifier that the replier would then include as a correlation identifier. (A message could have both a message Id and a correlation Id.) The requestor uses the correlation identifier to “jog its memory” concerning which request the response is for. But frequently, a request-reply is in context of a particular domain object, such as a terrain map or a bank transaction; but the correlation Id doesn’t include such information. To assist, the requestor can maintain a mapping (e.g., hashtable) between message Ids and relevant domain object Ids which are related to the original request. When the reply is received, the mapping may be used to load the appropriate domain objects and take further action, accordingly.

Obviously, it is important that the senders and receivers of a message system agree upon the format that messages will take for clear interoperability, better reusability of components, and extensibility of the system. Consequently, a canonical data model should be well defined that all applications will adhere to. The canonical data model does not dictate how each application's domain model must be structured, only how each application must format data within messages. Message translators are developed to convert the sending application's domain model into the canonical data model before sending a message; receivers of messages then use their own message translators to translate the message into their own domain. This mechanism allows applications built on completely different technologies (e.g., C#, Lisp, and C++) to communicate with each other and exchange data. Many off the shelf messaging systems define their canonical data model which must be adhered to. For example, the Robot Operating System (ROS), which we'll looking at in more detail in subsequent posts, defines their canonical model at http://www.ros.org/wiki/msg. But the canonical data model need not be limited to defining the types of primitives available and how to include them in messages.

Domain-specific canonical data models may augment message formatting rules, adding semantic meaning to the data within a message. For example, the Joint Architecture For Unmanned Systems (JAUS) is a set of message guidelines for the domain of unmanned systems, such as autonomous vehicles. The JAUS guidelines provide domain specific rules for communicating data, such as propulsion and braking commands, sensor events, pose and location information, etc. To demonstrate, JAUS message types include (Siciliano, 2008):

Command: initiate mode changes or actions,
Query: used to solicit information from a component,
Inform: response to a query,
Event set up: passes parameters to set up an event, and
Event notification: sent when the event happens.

A challenge in dealing with canonical data models is how to handle changes to the model. In order to support backwards compatibility of existing components when the canonical data model changes, new message channels could be created to carry the messages adhering to the model; e.g., "Perception/LaserScans_V1" and "Perception/LaserScans_V2." Alternatively, the existing channels could continue to be leveraged to carry messages adhering to different version of the canonical data model. To do so, the message, within its header, would include a format indicator, such as a version number or format document (e.g., DTD) reference. But if a sender knows that receivers of a particular message are mixed in what format is being used, a component would need to send two messages, one for each version of the canonical data model. Certainly, this is an important consideration when deciding which components should (or even can) be upgraded to newer formats, and in what order.

Message Routers

While the heavy lifting of the message routing is handled by the messaging middleware itself, there are times when it is useful to augment the middleware with custom message routers to support unique scenarios.

Suppose the destination of a message may change based on the number of messages that have already passed over a channel. In this scenario, the sender of a message may not know how many messages have been passed over a channel since other senders may have been publishing messages on the same channel. Consequently, a message router may subscribe to the channel to determine where each message should be forwarded to, based on the described business rules. Once the destination is determined, the router would then place the message on a subsequent channel to be delivered to the appropriate destination. This intermediary routing is described as predictive routing as the message router is aware of every possible destination and the rules for routing, accordingly. If the routing is based on content within the message itself, such as threshold values, then the custom router is known as a content-based router.

A drawback to using message routers is that if the routing rules change frequently, the message router will need to be modified just as often. To help remedy this, if the rules are expected to change frequently, configurable routing rules (e.g., via XML) could be employed to enable easier management of routing rules.

Let's now consider another scenario wherein it's left up to the subscribers to determine which messages they're interested in; i.e., subscribers will be responsible for filtering out the messages they're uninterested in. In this reactive routing scenario, each subscriber would provide a respective message filter which is similar to a message router, but simply forwards, or does not forward, a message onto a subsequent channel that the destination subscriber is listening to. Frequently, message filters decide to forward, or not forward, based on content in the message itself; e.g., only forwarding orders that have a coupon included. While being similar to a message router in basic functionality, a message filter only has one possible channel to forward the message onto.

Deciding between predictive and reactive filtering must take into account a number of considerations. Is the message content sensitive? Do you need to minimize network traffic? Do you need to be able to add and remove subscribers easily? Is the predictive router becoming a bottleneck of message dissemination? For further guidance on selecting among routing options, see (Hohpe, 2003), ppg. 241-242.

Message Endpoints

Each messaging middleware option (e.g., CCR, ROS) has unique requirements for communicating with it. Each has its own API, its own means of addressing channels, and its own rules for packaging messages. Ideally, the components of the system should not be aware of the specifics of communicating with the messaging middleware. Furthermore, while unlikely to occur, the middleware should be able to be replaced with another, requiring little, if any, changes to the components. Accordingly, the components must be loosely coupled to the messaging middleware. Message endpoints provide the bridge between the domain of each component and the API of the messaging middleware.

Message endpoints are similar in nature to repositories when communicating with a database. Repositories encapsulate the code required to communicate with a database to store and retrieve data while being able to convert information from the database into domain objects. If the database changes, or if the mechanism for database communication changes (e.g., ADO.NET to NHibernate), then, ideally, only the repositories are affected. The rest of the application knows little about database communications outside of the repository interfaces. Likewise, components of a message-based system should not be aware of messaging details outside of the message endpoint interfaces, which provide the means to send and receive data. The message endpoint accepts a command or data, converts it into a message, and publishes it onto the correct channel. Additionally, the message endpoint receives messages from a channel, converts the content into the domain of the component, and passes the domain objects to the component for further action. Internally, the message endpoint implements a message mapper to convert between the component domain objects and the canonical data model.

While posting to a channel is rather straight forward, a message endpoint may receive a message by acting as a:

Polling Consumer: wherein the receiver looks at a channel on a regular basis for new messages and/or as soon as it completes the processing of a previous message. This frees the receiver from having to deal with messages as soon as they arrive on the channel in favor of dealing with messages went it’s ready and willing. A consideration to keep in mind is that messages may queue up on a channel while waiting to be retrieved by the polling consumer. Additionally, a polling consumer may take up threads and resources while polling a channel, even if the channel is empty.
Event-Driven Consumer: wherein the message is given to the receiver as soon as it arrives on the channel. The benefits to this include avoiding messages queuing up while being able to process messages asynchronously. But the receiver is no longer in control of the timing in which it processes messages and must handle messages as soon as they arrive on a channel.

Many messaging middleware solutions include support for transactions that the message endpoints may leverage, making the endpoints transactional clients. To illustrate the need for this, suppose the receiver of a request-reply command crashes just moments after the command message is consumed and removed from the channel. When it recovers, the command message is lost and the sender will never receive a reply. Using a transaction, the command message is not removed from the channel until the response is completed and sent. Committing the transaction removes the command message from the channel and adds the reply document message to the reply channel.

There are a few recommendations which should be considered when developing message endpoints. In accordance with the SRP, message endpoints should be able to receive messages or send messages, but not both in the same message endpoint. Furthermore, a message endpoint should only communicate with one message channel. If a component needs to send a message on separate channels, it would leverage multiple message endpoints to do so. If your components are developed in line with DDD, it would be each component's application services layer which would communicate with the message endpoints, preferably via their interfaces instead of concrete instances. This facilitates swapping out the message endpoints with mock objects for unit testing. Leveraging separated interfaces and dependency injection helps enable this approach. While these guidelines introduce more objects and indirection, they are proven practices for increasing maintainability of the component and reusability of the message endpoints.

Performance of Message Based Systems

One would likely be quick to assume that developing a message-based system has a huge cost to performance. Domain objects are converted to messages, messages are passed over channels, routers and filters intercept and forward messages, and messages are converted back into domain objects...this sounds like a heck of a lot going on. But because each component executes in its own thread or process, they need not wait for other components to complete their job before being able to move on to handling another message or task.

In the figure above (adapted from Hohpe, 2003, pg. 73), note that a sequential process requires that each message life cycle is completed in full before moving on to the next message. But in an asynchronous, message-based system, each component can move onto a subsequent message just as soon as it has completed its part in the last one. This greatly compensates for the extra overhead imparted by the messaging infrastructure.

With that said, there are some component responsibilities which take a long time to complete and may impede the speed by which messages are processed. For example, imagine a component which takes images from a web cam and extracts information such as human figures or road signs. This is likely a time consuming process and would impact the turn around time in which the component could process subsequent messages. To alleviate this bottleneck, multiple instances of the same component may subscribe to the same point-to-point channel. Recall that a point-to-point channel ensures that each message only has a single receiver. The instances of the component then become competing consumers of each message. So if one instance of the component is still processing an earlier message, another instance can grab the next message that arrives for concurrent processing. Power in numbers!

Monitoring and Debugging

Due to the widely asynchronous nature of message-based systems, attention must be given to monitoring and debugging techniques to observe system behavior and iron out problems.

Logging message content is an invaluable measure towards getting a clear look at what communications are taking place. To facilitate this, logging could be added directly into sending and receiving components, but logging message content should not be a concern of components; accordingly, using a monitoring utility to log such information is a cleaner separation of concerns. Certainly a benefit of publish-subscribe channels is that a monitoring component may subscribe to all messages and log the information to a file or console window. While it’s just as valuable to monitor messages on point-to-point channels, if a monitor were to consume a message over a point-to-point channel, the message would be noted as consumed and would no longer be available to the intended receiver. Because such monitoring capability is so helpful in developing and debugging, many messaging middleware options include a "peek" option which allows a monitoring utility to review message contents on a point-to-point channel without actually consuming the message. This capability should be taken into consideration when comparing messaging middleware alternatives.

In addition to monitoring message content sent over channels, it’s also assistive to monitor active subscriptions to various channels to accurately determine which components are receiving which messages. This capability is typically built into messaging middleware solutions and is very assistive during development.

It’s possible that even if a message is routed appropriately, the receiving component may not know what to do with the message due to an incorrectly formatted header or body content. Invalid messages such as this should be forwarded to an invalid message channel which an error logging utility would monitor and log, accordingly. An invalid message channel is setup just like any other channel but with the intention of exposing such messages for debugging purposes.

Closing Thoughts

Developing asynchronous, message-based systems requires a paradigm shift from the more traditional, synchronously executed applications that most people are familiar with. It is not appropriate for every application domain and should be seen as one additional architectural option to consider when developing applications. But in some domains, such as robotics or in the integration of disparate applications, this approach to development is absolutely pivotal in providing responsive behavior without sacrificing maintainability of the overall system. Indeed, by splitting responsibilities into discrete components, loosely coupled to each other via messaging middleware, immensely complex problems can be broken down into understandable chunks while being flexible enough to accommodate changes to the underlying middleware or introduction of new components.

In the next couple of posts, we'll look at a checklist for developing message-based systems followed with examples in CCR and ROS.

Enjoy!

Billy McCafferty
http://wiki.sharparchitecture.net

P.S., for S#arp fans, we're trying to get another release together for the coming week...and this ain't no quarterly release. ;)

References

Hohpe, G., Woolf, B. 2003. Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions.

Siciliano, B., Khatib, O. 2008. Springer Handbook of Robotics.

MSpec Live Templates

Hadi Hariri — Mon, 01 Mar 2010 15:07:00 GMT

If you’re using MSpec (Machine.Specifications), you’ve no doubt run into the verbosity of it. Here’s a typical specification in MSpec

 [Subject("Registering as new a usergroup")]
public class when_requesting_registration_page
{
    Establish context = () =>
    {
    };
 
    Because of = () =>
    {
    };
 
    It should_display_blank_registration_form = () =>
    {
    };
}
 

The code is usually divided into three areas, the Establish that defines the context, Because which is defined as the action to take, and finally one or more benefits that are defined as It sections. Having this layout makes it easier to understand specifications and both the console runner as well as ReSharper’s MSpec runner remove underscores and provide a nice formatting.

Live Templates

However when it comes to typing all this in, well all those brackets and symbols become tiring. For that I normally use ReSharper Live Templates. If you’re not familiar with these, think of them as code snippets that allow interaction. Each template is uniquely identified by a shortcut, which is a series of characters. To invoke it, you simply type the characters and hit TAB. It then inserts some code. Up to this point it’s like a normal snippet. The twist however is that you can then TAB through placeholders and define values (I’ll cover Live Templates and all the possibilities it allows in a future post).

What I’ve been using for a while are some Live Templates for MSpec that allow me to define specifications with a little less effort. The first one is for empty specifications, which is useful for defining scenarios for features and then later proceeding to implement them, named espec. The second one is for the specifications and implementation, named spec.

To install them, the easiest way is to just open up Live Templates (ReSharper menu) and Import the following file.

Obviously these are just two simple versions and can be expanded on. For instance, if you use Behaviors in MSpec, you could write an additional one for that. Feel free to use them for your own needs.

Coding Concepts are Cross Language, because it is SQL does not means it should suck

Derik Whittaker — Mon, 01 Mar 2010 11:49:00 GMT

<Warning_Rant_AHead>

Today I was reviewing some commits by our team and I ran into one commit in general that first made me vomit a bit in my mouth, then get pissed as all hell that we committed code like this.

The code that was committed was a minor change to one of our ‘legacy’ (aka has no tests, written like a blind monkey coded it and god help the person who has to make changes to it) stored procs. Here are some details on the proc

Has about 2050 lines of code
Has about 141 variables
Has 6 Temp tables
Has > 50 update statements
Has ~13 delete statements
Has 8 Cursors

What makes me so mad is that this code when it was originally written was code reviewed by a senior developer on the team (I know this be cause like many other old school shops at that time we put our commit comments in the header of every file). I am going to bet the farm that had this been C# code and not SQL this would not have passed review. BUT for what ever reason SQL seems to be treated differently. When writing SQL many people throw best practices out the window, and I have NO clue why.

The one message I want to get across to anyone out there reading this is…. Code is Code and coding concepts are cross language. If while writing .net/java/ruby/etc code you follow practices like SRP, DRY, etc then why not follow those same principles when writing code in SQL (or any language for that fact)

</Warning_Rant_AHead>

Till next time

Issues Compiling VS2010 solutions (with web projects) from Nant

Derik Whittaker — Sat, 27 Feb 2010 14:40:00 GMT

Recently I upgraded a project of mine (the Dimecasts code base) to use VisualStudio 2010. In the process everything worked just fine from the IDE, but when I tried to compile it from the command line I would get the following errors:

Error MSB4064: The "Retries" parameter is not supported by the "Copy" task.
Error MSB4063: THe "Copy" task could be initialized with its input parameter.

After a bit a googling I came across a post which (and of course i cannot find it now) said that if you open up your .proj files and change the line that pointed to the v10.0 build of web applications and reset it back to 9.0 everything would compile. And this did work... BUT when you try to open that project up again in VS 2010 it will simply revert your changes... this is not a working solution.

Next I decided to switch my target framework in Nant from 3.5 to 4.0, but of course my nant.exe.config file does not support 4.0 yet. So after a bit more googling I found this post that gives details on how to add the missing values to the config file.

When I added the config information to my Nant.exe.config file things were better, but still not great. Now I was getting an error that said:

The "vendor" attribute does not exist, or has no value.

To resolve this I added the following under the <framework> node in my config
vendor="Microsoft"

After this I got another error.... This time it said that .Net Framework 4.0 was not installed. But I know this is not valid. After looking at the information for a few more seconds I realized the issue. The example config from the post above was build on an older version of the 4.0 framework (.20506) and I have .30128.

I changed all values in the nant.exe.config value that was v4.0.20506 to be v4.0.30128 and NOW I am able to compile.

So long story short, if you are getting the MSB4064 error you need to do the following:

Point nant to use the 4.0 framework tools
Follow this post and copy the framework section to your Nant.exe.config file
Add the missing 'vendor' attribute to the new framework section
Update the version in the new framework section to match the version you have on disk (check C:\Windows\Microsoft.NET\Framework for versions)
Compile again

Till next time,