January 2016 – Fun times with Functions

F# Type Providers: 0 to Data in a Single Line of Code

More and more I’ve been working in F#. Part of it is needing a REPL in an environment where I can’t use my normal tools. Part of it is that working in a different paradigm changes how I code. Overall, I love the language and learning it has been a blast!

Recently, however, I was listening to a great DNR with Rachel Reese and the subject of Type Providers was raised. They have tradeoffs like anything else, but imagine a fully typed model in a single line of code. Better yet, why don’t we make one?

Before we begin, I’m going to assume you have access to a SQL Server instance, a copy of Visual Studio, and F# installed. If anyone reading this either doesn’t have access or would like help getting set up, please let me know in the comments and I’ll try to assist.

Let’s start with a database. I’ll use Northwind for this example, but any will serve. Next, we need an F# class library project. Let’s call it TypeProviders.

You should start out in a new F# file, with the following:

namespace TypeProviders

type Class1() =
     member this.X = "F#"

Now we need to reference a few assemblies. For now, let’s go with System.Data.Linq, and FSharp.Data.TypeProviders.

Now I have a terrible confession. I lied. If we count open/using/import statements, it’s actually a whopping four lines of code:

namespace TypeProviders
 
open System.Data.Linq
open Microsoft.FSharp.Data.TypeProviders
open System.Linq
 
type public NorthwindContext = SqlDataConnection<"Connection-String-Here">

That’s it. You’re done. You now have a strongly typed model of the entire database! Don’t believe me? That’s fair. Let’s explore. Let’s open System.Linq and:

namespace TypeProviders
 
open System.Data.Linq
open Microsoft.FSharp.Data.TypeProviders
open System.Linq
 
type public NorthwindContext = SqlDataConnection<"Connection-String-Here">
 
module WorkingWithProvider =

     // Alias the type so we don't have to reference 
     // the full path to the type.
     type Shipper = NorthwindContext.ServiceTypes.Shippers

     // A function which determines whether the 
     // passed Shipper is named "Speedy Express"
     let nameIsSpeedy (company: Shipper) =
          company.CompanyName = "Speedy Express"

     // Grab SpeedyExpress from the database
     let speedy = NorthwindContext
                     .GetDataContext()
                     .Shippers
                     .Where(nameIsSpeedy)
                     .Single()

That’s it. We already can grab a particular entity from a particular table and we didn’t need to define a single one of the types. Where you see the type Shipper declared, we’re just aliasing it for readability.

“Ok. Not bad. What else?”

How about having your stored procedures automatically wired up for you?

// Maps directly to the Stored Proc
let getSalesByYear = NorthwindContext
                         .GetDataContext()
                         .SalesByYear

“Ok. That’s pretty cool. Problem is, I’m a C# developer. I can’t use this.”

Why not? It’s all IL, right? Let’s create a C# project called ConsumeTypeProvider:

Then we’ll reference our TypeProvider project and System.Data.Linq:

Voila:

static void Main(string[] args)
{
     var db = TypeProviders
                 .NorthwindContext
                 .GetDataContext()

     var speedy = db.Shippers
                    .Where
                    (x => x.CompanyName == "Speedy Express")
                    .Single();
}

“Ok. I can use it. Should I?”

Great question! It depends. Unless you alias the types, you’ll need to reference every type as [TypeProviderName].ServiceTypes.[ActualTypeName]. It’s a bit much.

Also, these aren’t EF Power Tools generated partial classes. Speaking of a bit much. If you want your model to have more functionality than the provided types, you’ll need to subclass them or write adapters, which cuts into the time savings.

“Any gotchas?”

Well, the data-context entities expose the System.Data.Linq.ITable interface. As an EF guy, I’m not a huge fan of the different API. Check back later and I’ll show you the more EF friendly Sql Type Provider.

Also, the Type Provider is, by default, dynamic. Every time you compile, it checks the database. That means compiling will be slower, but not enough that I mind.

You can set the Type Provider to a static schema, but I would advise against it. When dynamically generated each build, your Type Provider is a perfect reflection of your database. If the Type Provider changes its types such that it breaks your application, it means your database has been changed such that it breaks your application. Dynamic type generation can warn you if your database has breaking changes.

“Anything else?”

Yes, sorry. One last thing. There’s a lot more to Type Providers, and just this particular one, than I can show you in a single post. When you have time, there’s more information on MSDN.

InternalsVisibleTo

Just a quick tip. Every once in a while, you’ll need to share code between specific assemblies, and only those assemblies. A common example is when you want to strap a test-harness to an object, but not publicly expose the type.

/// <summary>
/// Vital component.
/// </summary>
/// <remarks>
/// Ensure stability but don't publicly expose.
/// </remarks>
internal static class CriticalComponent
{
}

Sometimes you just need to expose an object, type, or method to another specific assembly. Fortunately, you can!

using System.Reflection;
using System.Runtime.CompilerServices;
using System.Runtime.InteropServices;
 
// Allow ExampleAssembly.Tests to test internals
[assembly: InternalsVisibleTo("ExampleAssembly.Tests")]
 
// General Information about an assembly is controlled 
// through the following set of attributes. Change 
// these attribute values to modify the information
// associated with an assembly.
[assembly: AssemblyTitle("ExampleAssembly")]

Check out the MSDN for full details. It’s a handy thing when you need it. Oh, and remember to put your assembly attributes in your AssemblyInfo file.

Something put between the foot and the shoe.

Since my very first app in C#, I’ve felt a bit like an, admittedly boring, non-conformist. It started at DeVry with the traditional Hello World project, for which I received a whopping 0 of 100. When I asked the professor how on earth a functioning program which fully matched the project requirements could be a complete failure, the professor explained that I failed for not having comments.

Apparently, the following program is so vastly complicated as to be incomprehensible without the accompanying green text.

	public static void Main(string[] args)
	{
	// Writes "Hello World" to the console.
	Console.WriteLine("Hello World");
	}

view raw HelloWordCSharp.cs hosted with ❤ by GitHub

Now the professor, you, and I all know that the comment doesn’t really help in this case. What’s important is, it reinforces the good habit of commenting your code. Really though, how good a habit is it?

One of my favorite stories from the excellent show QI, is the line about Samuel Johnson’s definition for, “sock.” You guessed it, “Something put between the foot and the shoe.” Astonishing in it’s clarity, right? Imagine you have no idea what a sock is. How many possible items could it be? What material is used to make it? Most importantly, why are you putting it between the foot and the shoe?!

Without knowing what purpose the object serves, how are we to use it correctly? Yet, I consistently see definitions such as this in comments, or worse yet, the dreaded:

	/// <summary>
	/// Sock
	/// </summary>
	public Sock Sock { get; set; }

view raw SimpleSock.cs hosted with ❤ by GitHub

Surely you jest! You mean to say that a property of type Sock, which you have named “Sock”, is a… Sock?! No!

So what’s my point? Not everyone’s a wordsmith. Too true. I struggle with comments all the time. My point is that we need to stop teaching new developers to mindlessly shove green text in their code. Where code and comments fail to add value, they reduce value. Every line read which does not enhance understanding, is a delay and a distraction on the path to grokking the solution.

If you can’t find a better descriptor for your field/property/method than the name itself, don’t bother putting in a comment. It just takes up space on your and my screen.

That said, try to leave useful comments which add value. If you’re using a little-known class, or a hot new open-source library, add a link to a good tutorial or the github page. Give the next guy a resource. If you can’t think of a way to add clarity to a property declaration, work on something else. Grab a coffee. Come back to it when the code is stale enough in your own mind that you can see what I’ll see. That would be the giant, “What in the Sam Hill is a Metaphor<string>?

Most of all, if the comment won’t add value, don’t write it. Comments aren’t there to please the professor, or Ms. Manners, or the standards committee. They’re there to help the next developer use your awesome tool. Oh, and remember, Dr. Johnson was a brilliant scholar. Even his definitions weren’t always perfect.

On a final note, I leave you my definition of a sock:

	/// <summary>
	/// A cloth sleeve which protects and insulates a foot.
	/// </summary>
	/// <remarks>
	/// A sock is generally a cloth tube with only one open
	/// end. It is worn over the foot and can help to keep
	/// the foot warm in cold weather, as well as prevent
	/// chafing when worn between the foot and a shoe, boot
	/// or similar garment.
	/// </remarks>
	/// <example>
	/// This shows the basic use of a sock. Please remember,
	/// the sock is worn over the foot and under the shoe.
	/// <code>
	/// class Foot
	/// {
	/// public Sneakers Shoes { get; set; }
	/// public Socks Socks { get; set; }
	///
	/// public void DonShoes()
	/// {
	/// this.DonSocks(this.Socks);
	/// this.ShoesWorn = true;
	/// }
	///
	/// public void DoffShoes()
	/// {
	/// this.DoffSocks(this.Socks);
	/// this.ShoesWorn = false;
	/// }
	/// }
	/// </code>
	/// </example>
	public class Sock
	{

	}

view raw MySock.cs hosted with ❤ by GitHub