WPF with F# – Not A Happy Mix

I’ve had a look at various samples of F#/WPF, and contrasted that with the experience I’ve gained over the last 15 months doing a lot of commercial WPF. I can see a lot of potential for F#, but not combined with WPF. Here’s why:

XAML

XAML is an XML based language for defining and instantiating object trees. It’s possible, indeed easy, to use away from WPF, but the most common usage today is surely with WPF. Here it functions as a kind of markup language for GUIs. Just as its a lot easier to create a web page in HTML than to create one using the DOM, so creating WPF Windows, Pages and User Controls is better done in XAML than masses of imperative code. In addition to layout, its relatively simple to define visual styles, animations, data bindings, and even quite powerful interactivity with triggers, all in XAML. The code behind a WPF form is often rather minimal. I’ll even go so far as to say, if you have a lot of code behind, you should probably review it.

F# isn’t a GUI markup language, just as C# wasn’t, and it makes little sense to replace XAML with F#.

Tool Support

When you a create a new form in WPF, you typically subclass the Window class (there are other candidate base classes). The XAML file is used at run time to instantiate each instance of this class (usually via a pre-compiled BAML data). If you use Visual Studio or Blend to create the form,  it creates the subclass as 2 C# partials – one with some necessary plumbing, and the other acting as the code behind file, for you to work in (Visual Studio does a good job of hiding the plumbing partial, but it’s there, with *.g.cs extension.)

There’s nothing  mysterious about the the generated partial, and we could re-create it in F#. However, there is no direct advantage to doing this – its more work, and just another source of potential bugs. We could create the tooling to avoid this problem, but F# has nothing like C#’s partial classes and we’d end up with the plumbing and code behind in one ugly file.

MVC

MVC being the Model View Controller Pattern. In WPF it’s more common to use a variations on that theme (M-V-MV DM-V-VM), but the idea remains the same – get a clean separation between the UI, the data, and the application logic (yes, “application logic” is very vague, and in practice we often have several controllers). Essentially, MVC is the means to make good on the idea of minimal code behind files.

No F# On The Client?

No need to throw away the baby with the bath water. I have outlined some good reasons to keep the WPF forms etc in XAML, and use the extant tools which will back that up with C#. That’s just the “V” in MVC though, and if we really have a clean separation, we can certainly explorer building the “M” and the “C” in F#. So, that’s what I’ll be doing next.

Incidentally, if you’re building an application that will generate a lot of WPF objects dynamically, and place much less reliance on XAML, then F# could be useful here. 3D and Data Visualization applications spring to mind.

Using LINQ To SQL in the F# WCF Web Service, Part 2

When we use LINQ To SQL in C#, the compiler doesn’t generate IL to implement our query – we want Sql Server to execute the query, and so IL would not be much good. Instead the compiler creates data that describes our query, in the form of a System.Linq.Expressions.Expression. When the query needs to be executed, LINQ To SQL examines the expression and converts it to the equivalent T-SQL, and sends that to the database for execution.

It follows, then, that if we want to use LINQ To SQL in F#, we’d like to get the F# compiler to convert our code into a System.Linq.Expressions.Expression. The surprising news is, the F# compiler can’t do this directly.

F# does have something equivalent; Quotations. If we place an expression within <@ and @>, we’ll get back not an executable expression, but an object of type Microsoft.FSharp.Quotations.Expr<a’>. This needs to be converted to a Linq expression, and the function Microsoft.FSharp.Data.Linq.SQL will do this for us, but we have explicitly apply this function to the quotation.

Our query is eventually expressed in (at least) these 5 forms, in this order:

1. F# Source
2. Microsoft.FSharp.Quotatons.Expr
3. System.Linq.Expressions.Expression
4. T-Sql
5. Sql Server Execution Plan

I said “at least” because there could will be intermediate forms, like the compiler’s AST.

When you try and use this method, you’re in for the next surprise. The supporting code for LINQ seems to exist only in the samples folders. As it’s not compiled up by default, searching your entire drive for the “FSharp.Linq.dll” is both futile and frustrating. When I’d finished cursing whoever called this build a “release candidate”, I copied the sample project over to the solution, deleted the usage sample files, and referenced this from the web service project.

OK, all the prep is done, let’s implement the methods. Firstly, lets open the necessary namespaces:

open System.ServiceModel
  
open Microsoft.FSharp.Quotations.Typed
open Microsoft.FSharp.Data.Linq
open Microsoft.FSharp.Linq.SequenceOps

open Coyote.FSWCF.AWDC
open Coyote.FSWCF.AWEntity

Those final two Coyote namespaces contain the data context and the data entities.

Now let’s define a useful interface:

[<ServiceContract(ConfigurationName = "ISimpleService", Namespace = "http://coyote-software.com/FSWCF/SimpleService")>]
type ISimpleService =
    [<OperationContract>]
    abstract GetContact: contactID:int -> seq<Contact>
    [<OperationContract>]
    abstract GetContacts: unit -> seq<Contact>

This is pretty much as we did before. The return types of seq<Contact> means, in standard .Net terms, IEnumberable<Contact>. WCF doesn’t marshal this (by reference) back to the client, instead the serializer iterates though it and places each item into an Xml document that is returned.

Finally, the web service itself:

[<ServiceBehavior()>]
type SimpleService() =
    let connString = "server=VMDBSERVER\\SQLEXPRESS;database=AdventureWorks;trusted_connection=True"
    interface ISimpleService with
        member x.GetContact contactID = 
                let awdc = new AdventureWorksDataContext(connString)
                SQL <@ seq { for c in %awdc.Contacts when c.ContactID = %contactID -> c } @>
        
        member x.GetContacts () = 
                let awdc = new AdventureWorksDataContext(connString)
                SQL <@ seq { for c in %awdc.Contacts -> c } |> take 50 @>

 

This code works, but we aren’t disposing the data context object. In fact, we can’t dispose of it directly, because it will be needed when the serializer iterates the results. Therefore, a better implementation might be:

[<ServiceBehavior()>]
type SimpleService() =
   let connString = "server=VMDBSERVER\\SQLEXPRESS;database=AdventureWorks;trusted_connection=True"
    interface ISimpleService with
        member x.GetContact contactID = 
                seq { use awdc = new AdventureWorksDataContext(connString)
                      yield! SQL <@ seq { for c in %awdc.Contacts when c.ContactID = %contactID -> c } @> }
        
        member x.GetContacts () = 
                seq { use awdc = new AdventureWorksDataContext(connString)
                      yield! SQL <@ seq { for c in %awdc.Contacts -> c } |> take 50 @> }

This wraps one sequence in another, and will create and dispose of the data context for each iterator that’s created.

This is still along way from being a deployable web service, but for now I want to follow the data to the client, and do something interactive there, with WPF.

Using LINQ To SQL in the F# WCF Web Service, Part 1

To use LINQ To SQL, we need a Data Context object to provide our point of entry. It might be possible to use a System.Data.Linq.DataContext object directly, but its more usual to derive from this class to make a database specific version. Additionally, we need classes to represent our “entities”. These define the mapping to the tables (or views) and columns.

We could code all this up by hand, but Visual Studio 2008 comes with the grandly named Object Relational Designer that makes short work of this. This is a graphical tool to define our data context and entities, and a code generator to spit out some C# when we’re done. The designer edits a .dbml file that defines the mapping, and the code generation is based on this, so it easy to refine these mappings as we go. There is also a command line tool, SqlMetal.exe, for those working without Visual Studio, or wanting to set up more complex build processes.

I don’t want to spend time on this part of the process; it’s exactly the same as if it was being done for consumption in C#, and there is plenty of coverage on MSDN. I will be posting the code for all of this soon.

I’ll be using the Microsoft AdventureWorks sample database, which can be downloaded here. This first test is based on the Contact table. The data entity class will also be called Contact. The web service will then be returning instances of this class – in other words, it will be our WCF Data Contract.

How then, are we going to get the WCF DataContract attribute onto this generated class? Happily, the LINQ team wondered about that too, and added a “Serialization Mode” flag to the O/R Designer. Its values are “None” and the curiously named “Unidirectional”, but the latter is the one we want.

A quick look at the generated class confirms this. Here’s a snippet to give you the idea of what’s generated:

    [Table(Name="Person.Contact")]
    [DataContract()]
    public partial class Contact : INotifyPropertyChanging, INotifyPropertyChanged
    {
        private string _Title;


        [Column(Storage="_Title", DbType="NVarChar(8)")]
        [DataMember(Order=3)]
        public string Title
        {
            get
            {
                return this._Title;
            }
            set
            {
                if ((this._Title != value))
                {
                    this.OnTitleChanging(value);
                    this.SendPropertyChanging();
                    this._Title = value;
                    this.SendPropertyChanged("Title");
                    this.OnTitleChanged();
                }
            }
        }

Just a couple of comments before moving on to using this stuff from F#.

• The class is marked as partial. This allows us to create another source file in the same project containing more fields, methods and properties for this class. Its perfect for code generators, because it allows clean separation between generated and hand-written code. F# does not seem to have such a feature, but I think it should.
• The entity is by default a POCO. As with WCF, everything that LINQ to SQL needs is added via attributes.
• The setter shown here looks busy, but the OnXXX methods are partial methods. If these are not implemented in another partial part of this class, the compile drops the calls. Again, a nice mechanism targeted at code generators, but missing from F#.

This code needs to be compiled up into an assembly, and referenced from the F# project.

Problems with WCF Data Contracts in F#

On the road to a really interesting Web Service, I increased the complexity of my “could-not-be-simpler” web service one notch, and added a class-typed argument to the operation. This requires constructing of a Data Contract, so that WCF can build the correct WSDL, and also know how to serialize (and de-serialize) messages. As with the Service Contract, this is simply done with a couple of attributes, like this:

[<DataContract>]
type public SimpleDataContract() =
        let mutable _propertyOne = System.String.Empty
        let mutable _propetyTwo = 0
        [<DataMember>]
        member public x.PropertyOne
            with get() = _propertyOne
            and set(value) = _propertyOne <- value           
        [<DataMember>]
        member public x.PropertyTwo
            with get() = _propetyTwo
            and set(value) = _propetyTwo <- value

[<ServiceContract(ConfigurationName = "ISimpleService", Namespace = "http://coyote-software.com/FSWCF/SimpleService")>]
type ISimpleService =
    [<OperationContract>]
    abstract TestMethod: Param:SimpleDataContract -> string

[<ServiceBehavior(InstanceContextMode = InstanceContextMode.PerSession)>]
type SimpleService() =
    interface ISimpleService with
        member x.TestMethod s = "Hello " + s.PropertyOne;

Unfortunately, code causes a run-time exception when the service is started (well before any messages arrive). The error is about “method get_PropertyOne” not being a property, and therefore an invalid recipient of the DataMember attribute. I strongly suspect that this is due to a know bug in the current F# compiler emitting IL for properties in a non-standard way.

(WCF data contract members must be placed on properties, and not fields.)

The obvious work-around is to create the class in C#. The equivalent C# class is simply:

    [DataContract]
    public class SimpleDataContract
    {
        public SimpleDataContract() { }        [DataMember]
        public string PropertyOne { get; set; }
        [DataMember]
        public int PropertyTwo { get; set; }
    }

For once, C# trumps F# for brevity! Anyway, using this class from F# is no more complex than referencing the dll, and removing the F# SimpleDataContract class, and the web service now works as expected.

The next step is to do something a little more interesting in the operation; use LINQ to SQL to query a database, and return some data. As it turns out, our data contracts will be again come via C#, so this issue will be by-passed.

An WCF Service Host in F#

I had half an hour to fill while I waited for a large download, on my slow connection. I’d thought about re-implementing my C# WCF test host in F#. It didn’t look too complex, and indeed it wasn’t:

#light
#I @"C:\Program Files\Reference Assemblies\Microsoft\Framework\v3.0\"
#r "System.ServiceModel.dll"
#r "Server.dll"
open System
open System.ServiceModel
open System.Diagnostics
open Coyote.FSWCFTest

let services = [ (typeof<TestWebService>, "http://localhost:8080/Test/FSWCFTest.svc") ]

let logException (msg, exn:Exception) =
    Trace.TraceWarning(msg)
    Trace.WriteLine(exn.Message)
    Trace.WriteLine(exn.Source)

let startHost (serviceType:Type, url) =
    try
        let uri = [| new Uri(url) |]
        let host = new ServiceHost(serviceType, uri)
        host.Open()
        Some(host)
    with
    | e -> logException ("Exception thrown starting service.", e)
           None

let stopHost (host: ServiceHost option)  =
    try
        match host with
        | None -> ()
        | Some(host) ->
            if host.State <> CommunicationState.Closed then
                host.Close()
                Trace.WriteLine("Service Stopped")               
    with
    | e -> logException ("Exception thrown stopping service.", e)

let showHostStatus (host: ServiceHost option) =
    match host with
    | Some(hst) ->
        let strdots = new String ( '.', 40 - hst.Description.Name.Length);
        Console.ForegroundColor <- match hst.State with
                                   | CommunicationState.Opened -> ConsoleColor.Green
                                   | _ -> ConsoleColor.Red       
        Console.WriteLine("{0} service{1}{2}", hst.Description.Name, strdots, hst.State.ToString())
    | None -> Console.ForegroundColor <- ConsoleColor.Red
              Console.WriteLine("Service failed to start.")

let main =
    Console.Title <- "Server Test Console"
    Console.BackgroundColor <- ConsoleColor.DarkBlue
    Console.WindowWidth <- 120
    Console.Clear()
    Console.WriteLine("Server Test Console")
    Console.WriteLine("Copyright 2008 Coyote Software, GmbH.")
    Console.WriteLine()
    let hosts = services |> List.map startHost
    let mutable quit = false
    while not quit do
        let inp = Console.ReadLine()  
        let inpClean = inp.Trim().ToLower()
        match inpClean with
        | "exit"   -> quit <- true
        | "cls"    -> Console.Clear()
        | "status" -> let cc = Console.ForegroundColor
                      Console.WriteLine("Status at {0} is", DateTime.Now)
                      hosts |> List.iter showHostStatus
                      Console.ForegroundColor <- cc      
        | "stop"   -> hosts |> List.iter stopHost
        | _        -> Console.WriteLine("Unknown command {0}", inp)
    done

This implementation is about half the size of the C# implementation, although the original has a couple of extra commands. I preferred Console.WriteLine to printfn, as I have used other Console methods, and I think the code is a little clearer.

One improvement to this app would be to have is use reflection to automatically find all  the services in the assembly (rather than require the list to be set up), but I’ve been using the C# version almost daily for over a year, and its good enough like this.

Accessing F# Interface Implementations from C#

I tidied up the F# web service, mainly by factoring out an interface for the web service. Without the attributes it looks like this:

type ITestWebService =
    abstract TestMethod: Param:string -> string type TestWebService() =
    interface ITestWebService with
        member x.TestMethod s = "Hello " + s;

However, I noticed when I was setting up the C# host, I needed to cast to get to access the interface, like this:

TestWebService tws = new TestWebService();
ITestWebService itws = tws as ITestWebService;

Neither of these far more obvious ways to access the member work:

tws.TestMethod("test");                     // Doesn't compile
tws.ITestWebService.TestMethod("test");     // Doesn't compile 

I have no idea why.

An F# WCF Web Service

For all the power and flexibility that WCF provides, creating a basic web service in C# is easy enough. Essentially, it’s just a POCO adorned with some special attributes. Doing the same thing in F#, then, should also be easy enough. I tried this:

#light
#I @"C:\Program Files\Reference Assemblies\Microsoft\Framework\v3.0\"
#r "System.ServiceModel.dll"

open System.ServiceModel


[<ServiceContract(ConfigurationName = "TestWebService", Namespace = "http://coyote-software.com/FSWCFTest")>]
[<ServiceBehavior(InstanceContextMode=InstanceContextMode.PerCall)>]
type public TestWebService =
    class
        [<OperationContract>]
        member public x.TestMethod(s) = "Hello " + s;
    end

Essentially, I’ve referenced the WCF assembly, and created a class with a single method, and added the needed ServiceContract, ServiceBehavior and OperationContract attributes. I compiled this into to a dll.

To test this, I needed to host it somewhere. I already have a console host application in C#, and so I used that for testing, and got this exception:

The service type provided could not be loaded as a service because it does not have a default (parameter-less) constructor.

Constructors in F# are a little different to C#, and a bit of hunting through the spec, and I had my solution:

type public TestWebService() =

Just a pair of missing parenthesis! This was going extremely well, so the next task is to call the method. For this we need to generate a client proxy with svcutil.exe. This generates C# code, but no reason not to use this, driven from an F# client. I compiled up the generated C# into a dll, and then referenced that from a simple F# console client:

#light
#I @"C:\Program Files\Reference Assemblies\Microsoft\Framework\v3.0\"
#I @"c:\Development Projects\Research\FSWCF\Client\bin\debug\"
#r "System.ServiceModel.dll"
#r "client.dll"open System

do
    let service = new TestWebServiceClient()
    let retVal = service.TestMethod "Nick"
    printfn "%s" retVal
    Console.ReadLine() |> ignore

This resulted in “Hello Nick” on the console. It was extremely simple to get this (albeit trivial) web service running.

What I’ve not done yet is pass a more complex data contract, but that will come with in the next step, using LINQ-to-Sql to grab some data, and pass that back to the client.

Curried Functions In C#

I previously said that C#’s lambda functions were not curried, and it wasn’t possible to partially apply them. However, it’s usually possible to manually curry functions, if you need to. Here is an example:

static void Main(string[] args)
{
    int t = f(1)(3)(5)(7);

    Console.WriteLine("{0}", t);

    var g = f(1);
    var h = g(3);
    var i = h(5);
    int j = i(7);

    Console.WriteLine("{0}", j);
}

static Func<int, Func<int, Func<int, int>>> f(int a)
{
    return (b => c => d => (a + b + c + d));
}

It’s interesting to step through that code in Visual Studio. As the complex lambda expression is repeatedly returned to, the highlighting outlines exactly which sub-function is being evaluated. However, the return type of the f is not at all easy to read (although the new C# 3.0 var keyword means we don’t need to repeat this horror for g, h, & i). The equivalent code in F# is far more svelte:

let f a b c d = a + b + c + d

Even with my cryptically short function name, its clear what this function does. There’s one more thing on curried functions I want to look at, but before that I’m going to look at implementing Web Services in F# and WCF.

Many Choices.

Some years ago, when faced with sorting out a large and troubled project on a very short timescale, my colleague (Ivo) and I started the evolution of a code generation strategy for handling various aspects of n-tier applications. We published a paper at the time (Metadata Driven Code Generation Using .Net Framework), and the toolset we produced, QuickStrike, we maintain to this day, and it has been used on a number of very different projects with good success.

A particularly pleasing moment came early last year, when we were presented with the requirement to move an existing code base from COM+ (EnterpriseServices) to WCF. What could have been a long and disruptive task was accomplished in just a few days work.

Despite all benefits gained to date, it’s increasingly clear that at the very least, a detailed review of possible alternative implementations is in order, both for the final code, and for the tooling itself.

Many interesting technologies have appeared on the .Net platform in the last year or so (LINQ, F#, DLR, ADO.NET Entity Framework, WCF, WPF and WF spring to mind, but there are more), and we’ve got some significant experience already on many of these, but in isolation. What we will be looking for next are the interesting ways to combine all this stuff in the never ending quest for building apps better, and faster.

Do I have to have a curried function in F#?

All this currying and partial application stuff is all very interesting, but surely its has to have some kind of run-time performance hit. What if I just want to keep things straightforward?

Firstly, if we have a function that takes only a single argument, there is nothing to curry. It makes no sense to call a function with no arguments, so your only option is to make the exact call.

That in mind, we can do this:

let repeat(str, n) = ...

That syntax is sure to catch out C# programmers (like me), because it looks a lot like a normal C# function call. You might not even register, at first glance, the extra parenthesis around the arguments. However, these parenthesis are nothing to do with the function syntax, but everything to do with tuples:

let name = ("Fred", "Smith")

here, name is equal to the pair of values “Fred” and “Smith”. Tuples can have more than 2 components. The type is reported as:

val x : string * string

Personally, I find that * as the separator a bit jarring, but I assume there is a good reason to use it in preference to “,” – maybe it will come to light some day.

Anyway, a tuple is a simple data structure that allows you to group 2 or more components into a single argument, and thereby create functions that need not be curried.