Blog

All posts

F# is Changing My Style

Tonight, I was writing some code that made use of transactional WCF bindings. I wanted to do some experimentation with all the bindings available to see which ones support flowing transactions. The pre-built bindings that do this will create a TransactionFlowBindingElement when you ask them to call CreateBindingElements(). The types I’m interested are concrete (no abstract methods) and have a zero-argument constructor. A few years ago, I would have done a bunch of looping constructs to look at each element. However, I’ve been doing a lot more work with F#. While doing this experiment in C# for a project, I wound up writing the following instead:

 

static void Main(string[] args)
{
    var bindings = from bindingType in typeof (MessageContractAttribute).
                       Assembly.GetTypes()
                   where typeof (Binding).IsAssignableFrom(bindingType) && 
                   !bindingType.IsAbstract && 
                   (from constructorInfo in bindingType.GetConstructors()
                           where constructorInfo.GetParameters().Length == 0
                           select constructorInfo).Count() > 0
                   select bindingType;

    var txBindings = from bindingType in bindings
                     where
                         (from bindingElement in
                              ((Binding) Activator.CreateInstance(
                                bindingType)).CreateBindingElements()
                          where bindingElement.GetType() == 
                            typeof (TransactionFlowBindingElement)
                          select bindingElement).Count() > 0
                     select bindingType;
    foreach (var txBinding in txBindings)  
        Console.WriteLine(txBinding.FullName);
}

I would’ve loved a Seq.iter for the last 2 lines of the function. I think this is a good reason to learn F# or another functional language. It’ll change how you write code elsewhere. I’m not saying that this code is more readable, but it is interesting.

So, what does the code write out as the transaction supporting bindings?

System.ServiceModel.NetTcpBinding
System.ServiceModel.NetTcpContextBinding
System.ServiceModel.WSHttpBinding
System.ServiceModel.WSHttpContextBinding
System.ServiceModel.NetNamedPipeBinding
System.ServiceModel.WSFederationHttpBinding
System.ServiceModel.WS2007FederationHttpBinding
System.ServiceModel.WS2007HttpBinding
System.ServiceModel.WSDualHttpBinding

Comments  6

  • Cameron Taggart 14 Jan, 02:32 AM

    Nice post. I still like it better in F#:
    http://blog.ctaggart.com/2010/01/list-transactional-wcf-bindings-in-f.html

  • kurt schroeder 20 Jan, 12:07 PM

    I'm still trrying to figure out if technologies and languages infulenceing the way i code is a good thing or a bad thing. I like it that I'm not confused about. I read this post a few days ago. Today i'm doing a light import export (i'm hoping i can create a REST service for both, but that depends on the client). With out realizing it i've been creating this project in the style and layout i'm using for NHibernate.
    I guess i'm saying, point taken!

  • http:///trackback.ashx 29 Jan, 02:16 PM

  • http:///trackback.ashx 9 Feb, 05:17 AM

  • http:///trackback.ashx 25 Feb, 04:31 PM

  • Frank de Groot - Schouten 26 Feb, 01:32 AM

    I really like this style over the classic pile of foreach statements. This particular code is a bit hard to read because of the slim layout but it's foreach equivalent would be quite a bit longer I suspect.

    And anyway you could split things up a bit to make it even more readable.

    In some C# article I've read that the LINQ team deliberately didn't include a LINQ method to replace foreach because it is specifically intended to cause side effects. They reasoned that a statement is a better fit than a function. This is different for F# of course, but I think they have a good point.

Post a comment!