Sending messages in your application

I got a question from a friend the other day that went something like this:

I have an application that has n modules, and I need to communicate between them.  I have been using some messaging stuff for a while now, and as my application has gotten more complicated, it has become messy.  How are you doing this?

Communication between modules in any application is always tricky, and can always get messy.  Think of it this way.  What if I wanted to send a text message to somebody.  Only, instead of sending it to somebody, I had to hope the right person / people were expecting my message, and would act appropriately.  And, conversely, i would also hope people who were not supposed to be listening were not, and didn’t do anything when I sent the message.  See Twitter and it’s incredible reliability.

So how do you solve this problem?  Well, the quickest way is to download a messaging framework like Courier (thanks Brad!).  Now you can send messages where ever you want!  Although I am not a fan of the messaging idea, I really like everything in my application to be as defined as possible.  I have never really felt comfortable sending a message “SelectedItem” with the item selected attached to it as an object.  I just don’t like it when I have to count on my subscriber to convert my object to the right thing (boxing and unboxing concerns aside).

My preferred way to solve this problem is to created an object who's sole responsibility is to keep track of the selected item.  Then, using my favorite dependency injection framework, I would register the ItemSelector and anything that needed a reference to my item selection object could get at it.  Here’s what the interface would look like:

This defines all the pieces we need for the selection, now for the implementation of the interface:

Now, any part of my code that might need to know about selection change, just needs to have a reference to the instance of ItemSelector (or, if you are using dependency injection, would just need to be injected with the IItemSelector interface).  Of course, the standard cautions apply to subscribing and then UNSUBSCRIBING from events.  But this should work fine, and can be expanded to fit the needs of your complexity. Post + Comments

PDC, Day 1

Keynote

In the keynote, there was a ton of talk about Windows Azure, which wasn’t really very new from last year.  Microsoft is going live with Azure starting at the beginning of this year, followed by the start of billing in February.  Again, not really new stuff, but I think everything will eventually end up in the cloud.  If Microsoft can continue to separate the implementation of this so I don’t have to think about which platform to target as a developer, it’s going to be a nice win.

Sessions

Future Directions of C# and Visual Basic

First, Luca is a great guy to listen to talk.  I heard him once before talking about F# at a code camp and he is a fun guy to listen to.  Good stuff here about languages.  Really enjoyed the talk about dynamic stuff.  I have to admit I have been a bit of a pessimist about the general use of var, and dynamic only took that further.  This really helped me understand how the dynamic type works, was well as how the compiler treats the dynamic type.  Good stuff also about how the DLR caches the use of run time binding.  Also, Microsoft is toying with the notion of not only writing the compiler in their native languages, but opening up the compilers for use by you and me!

SQL Azure Database: Present and Future

One word to describe this: overwhelming.  The SQL Azure team has done a great job of abstracting the implementation of this service.  There is still some stuff left to be desired, but this is getting really nice.  Lots of talking about low level implementations and how the SQL Azure encrypts and blocks out hacks.  Kind of confusing and this pretty much fried my brain.

Sketchflow: Prototyping to the rescue

I am now a huge fan of SketchFlow.  Great tool.  If you are prototyping anything XAMLy, this is for you.  Great new font that purposefully dumbs down the look of the application so users can focus on functionality, not why the button font isn’t Arial Bold with a Green to Blue radial gradient.  Check out this session.  Definitely my surprise favorite session of the day.

Post + Comments

Unit Tests and the PrivateObject, Part 1

As a developer, it’s hard to stick to writing unit tests.  It’s really awesome if you do test driven development and write them first, but a lot of the times I find it hard to sick to this plan for various reasons.  No, it’s not cause I don’t want to….sort of.

One of the really cool things about the unit test framework built into visual studio, is the ability to create a unit test that will test even your private methods.  You can do this by right clicking in the .cs and selecting the “Create Private Accessor” option, which will then offer you the list of test projects to generate this class in.  Here is the menu:

 

You can read more about doing this here.  Now, we should be able create an instance of you new accessor in the unit test by instantiating MyObject_Accessor.  In the instance of the object, you should now have access to all of the fields and methods of the original object that are not public.  Sweet.

Hanging off of this accessor object, you will see a property called Target, of type Object.  This holds something called a PrivateObject, which should be a wrapper around your original object, MyObject.  I have been doing a ton of Dependency Injection in my projects lately using Unity to decouple my projects from eachother.  Using the PrivateObject is critical to creating a mock version of my dependency injector for the purposes of unit testing.

In a follow up to this, I will post some code showing how to create a mock injector, and how to make use of the PrivateObject in that injector.  Now go test!

Post + Comments