Some thoughts about Indigo
time to read 3 min | 476 words

So I was at the Israeli C# User Group meeting today, and the topic was Indigo, or in the odious name Windows Communications Foundation. Ido had a great presentation about it. I was surprised by how familiar the concepts were to me. There were quite a bit of stuff that that was very familiar to me from Castle (like TransactionScope, TransactionalAttribute, etc).

The architecture looks very extensible and well thought out, and I like the extensability points that they have there. The ability to intercept a method is invaluable in complex scenarios, since you can add behavior to it easily.

The Indigo way of doing it is just cool:

public class IndigoCacheAttribute : Attribute, IOperationInvoker 
{
...
}

The attribute is both the marker and the actor in this case. 

I wish I had something to do with it now, beyond writing the umpteenth calculator service, of course. One really nice thing that I liked about it was that you don't see XML if you don't want to (and I usually won't want to :-)). The programming model seems very easy to work with, with one exception.

You've better not expose ordinary method signatures, but expose methods that takes and return DTOs (or messages, if you like to think about it this way). The reason for that is that you can add stuff later without breaking your code. I know that usually SOA guys like to say Message This & Message That, but when I see something like:

[DataContract]
public class Book
{
 [DataMember]
 public string Title;
 [DataMember]
 public string ISBN;
}

I think DTO, not Message. The fact that it is XML under the cover has better remain under the cover, I much rather work with objects than with raw XML. Now I have another new thing to add to the stack of stuff waiting to be explored, it's just about my height now, and it's getter bigger.

Tweet Share Share 0 comments
Tags: