Using single case union types for entity IDs in F# and make it work with Dapper

In C# it is a common and popular pattern to use strongly typed entity IDs instead of using integers or the likes for IDs on your entities. Strongly typed entity IDs is a great help when trying to prevent you from mixing an Order ID with an OrderLine ID.

Andrew Lock recently wrote a series on the topic that you should go read now.

A strongly typed entity ID may look something like this (the example used by Andrew Lock):

public readonly struct OrderId : IComparable<OrderId>, IEquatable<OrderId>
{
    public int Value { get; }

    public OrderId(int value)
    {
        Value = value;
    }

    public bool Equals(OrderId other) => this.Value.Equals(other.Value);
    public int CompareTo(OrderId other) => Value.CompareTo(other.Value);

    public override bool Equals(object obj)
    {
        if (ReferenceEquals(null, obj)) return false;
        return obj is OrderId other && Equals(other);
    }

    public override int GetHashCode() => Value.GetHashCode();
    public override string ToString() => Value.ToString();

    public static bool operator ==(OrderId a, OrderId b) => a.CompareTo(b) == 0;
    public static bool operator !=(OrderId a, OrderId b) => !(a == b);
}

That is a lot of code to write for every ID in your domain model and you should create a code snippet in Visual Studio to do it. However, as with many things you get this more or less for free in F# with single case union types. All it takes is this:

type CarID = CarID of int

F# will give to equal operators and the other stuff for free, hence:

let id1 = (CarID 42)
let id2 = (CarID 42)

id1 = id2 // true

As Scott Wlaschin points out on the legendary F# for fun and profit you can use single case union types for anything, not just IDs:

module Domain =
    type CarID = CarID of int
    type CarMake = CarMake of string
    type Model = Model of string

    type Car = {
        CarID: CarID;
        Make: CarMake;
        Year: int;
        Model: Model;
    }

I am not saying this is always a good idea but don’t take it for any more than an example.

What happens if you try to read a Car from a database with Dapper?

Single case union types and Dapper

Dapper uses reflection to create instances of your entity types either by calling the appropriate constructor or by setting properties. For F# record types you cannot set the properties so Dapper tries to call the constructor when querying the database:

use cn = getConnection ()
let cars = cn.Query<Car>("SELECT CarID, Make, Year, Model FROM Car")

This will fail because Dapper tries to find a constructor on OrderLine with the signature (int * string * int * string).

To help Dapper convert from int to CarID, from string to Make and so on you can register a type handler with Dapper. A type handler is a class that inherits SqlMapper.TypeHandler<>. For reading CarID from the database the type handler would look like this.

    type CarIDTypeHandler() =
        inherit SqlMapper.TypeHandler<CarID>()

        override x.SetValue(parameter: IDbDataParameter, value: CarID) =
            ()
        
        override x.Parse(value: obj) = 
            (CarID (Convert.ToInt32(value)))

You register the type handler with Dapper with SqlMapper.AddTypeHandler(typeof<CarID>, new CarIDTypeHandler()). It gets boring very quickly to write type handlers for every single single case union type you come up with (sorry about that strange sentence) and fortunately there is a way to write a generic type handler for single case union types using reflection.

    type SingleCaseUnionTypeHandler<'T>() =
        inherit SqlMapper.TypeHandler<'T>()

        override x.SetValue(parameter: IDbDataParameter, value: 'T) =
            ()
    
        override x.Parse(value: obj) =
            let cases = FSharpType.GetUnionCases(typedefof<'T>)
            FSharpValue.MakeUnion(cases.[0], [| value |]) :?> 'T

The last line makes use of FSharpValue.MakeUnion to create a union. It assumes that the union type 'T has one and only one case when using cases.[0]. I have not found a way to restrict the generic type parameter to unions.

Now you can register the type handler for all single case union types:

SqlMapper.AddTypeHandler(typeof<CarID>, new SingleCaseUnionTypeHandler<CarID>())
SqlMapper.AddTypeHandler(typeof<CarMake>, new SingleCaseUnionTypeHandler<CarMake>())
SqlMapper.AddTypeHandler(typeof<Model>, new SingleCaseUnionTypeHandler<Model>())

Closing

Above we have seen how we can easily use single case union types for type safe handling of entity IDs and other values to prevent using them interchangeably. We have also created a generic Dapper type handler for single case union types.

The generic type handler is only suitable for cases where you do not need extra logic or validation for creating your single union value types and you should also be careful when it comes to performance issues with the reflection in case you need to handle large amounts of instances.

Which is better for teaching? C# or F#

Recently I have had the pleasure of training a couple of colleagues in the wonders of programming. At work we use C# for most of our applications so naturally I started preparing my material in C#.

I did not get very far before it occurred to me: This is going to be a long haul…

Now, my colleagues are smart, really smart, much smarter than me, but they do not have much experience in programming. They have been using SQL, some VBA, and perhaps a bit of R, but none of them have been doing real application development and they know nothing about OO theory.

Unfortunately, you do not get very far with a language such as C# without knowing just a little bit about OO programming.

Let’s start with the compulsory and useless “Hello, world” example:

using System;

namespace ConsoleApp
{
class Program
{
static void Main(string[] args)
{
Console.WriteLine("Hello, world");
}
}
}

That’s a lot of code just to print out a stupid message on the screen.

“What are all those things for?” my colleague complains and I answer “We’ll get to namespaces, classes, static, void, arrays, and more stuff later”. He’s not happy and continues “Do I really need to write all those curly braces and semicolons?”. And when I tell him yes, and don’t forget that it’s all case sensitive, he breaks down and says “I miss VBA…”.

Of course curly brackets and case sensitivity has nothing to do with OO but I think we can all agree that OO is really, really hard. Heck, I don’t even master it after years of C++ and C#.

I find that it takes a long time for beginners to grasp OO and when they start to see the light they will abuse inheritance and create everything as singletons. And interfaces seem to be impossible to understand even though I do my best with lousy metafors such as cars and DVD playsers.

Usually, beginners actually tend to completely ignore that C# is object oriented and they take a straight forward approach and create a very long Main function.

So, perhaps teaching my colleagues C# is not the right approach. Perhaps I should try teaching them a functional language instead such as F#? Now, I am not saying that functional languages are easy but I do think that you can get really far with F# without knowing advanced stuff such as monads. In F# the “Hello, world” example boils down to

printfn "Hello, world"

Very simple. Not much to talk about.

Besides, there are a couple of important points to consider when bringing F# to the table:

  • My colleagues are all mathematicians and functional languages are perfect for math stuff.
  • F# is a .NET language and will work together with all the C# code in our company.
  • F# can work as a scripting language for makeshift assignments.

I am thinking that it would suffice to teach the basics of F# such as record types, functions, pattern matching, the Seq module, type providers, and perhaps partial application.

What do you think? Would F# be easier to grasp or should I go for the usual C#?

Setting up ASP.NET Core in Visual Studio 2017 with npm, webpack, and TypeScript: Part II

Example code on Github.

This is the second part in my small series on ASP.NET Core and the coolest of the cool JavaScript libraries out there, except that they are probably already outdated by the time I finish writing this.

In part I we took a look on how to install npm and webpack into our ASP.NET Core project. In this part we will set up TypeScript. Visual Studio (VS) will compile TypeScript for you automatically but we will disable that feature and let webpack do the TypeScript build just for the fun of it.

Set up TypeScript
Start by installing TypeScript using npm (this is all described on in webpack’s documentation):

npm install --save-dev typescript ts-loader

Notice how package.json is updated with typescript and ts-loader. You may be wondering what ts-loader is. I know I was. It is a “TypeScript loader for webpack” which really does not say much but it is the thing that makes webpack take care of our TypeScript code.

While we are at it let’s install Knockout.js which we will use for building view models in TypeScript.

npm install --save-dev knockout @types/knockout

By using @types we tell npm to install the typings for Knockout as well. I tend to think of typings being to TypeScript what header-files are to C++. The typings go into the node_modules folder as everything else.

Next we need to create a configuration file for TypeScript. Right-click your project node in VS solution explorer and click “Add New Item”. Search for “json” in the templates dialog and choose “TypeScript JSON Configuration File”. The file must be name “tsconfig.json”. Change the contents so that it looks something like this:

{
  "compilerOptions": {
    "outDir": "./wwwroot/build/",
    "noImplicitAny": false,
    "noEmitOnError": true,
    "removeComments": false,
    "sourceMap": true,
    "target": "es5",
    "module": "commonjs",
    "moduleResolution": "node",
    "compileOnSave": true
  },
  "exclude": [
    "node_modules",
    "wwwroot"
  ]
}

Notice that I have told the TypeScript loader to put the generated .js files in the folder “wwwroot/build”, and that I have told it to resolve any 3rd party modules by using “node” (i.e. it will look in the “node_modules” folder).

Test TypeScript build
Let us test that we can build TypeScript files. By default VS will build what ever .ts files you add to the project. Start by creating af Scripts folder in your project next to the wwwroot folder. Add a TypeScript a file named “myviewmodel.ts” to the folder. We will create a Knockout view model class so start by importing Knockout to the .ts file by adding the following line at the top.

import * as ko from "knockout"

Note how VS IntelliSense kicks in as you type. Very cool. Above we set “modeResolution” to “node” so that the TypeScript loader knows to look in node_modules to find Knockout. Now lets add a view model with two observable fields using the Knockout TypeScript definitions. The last line applies the Knockout bindings to the view.

import * as ko from "knockout"

class MyViewModel {
    firstname: KnockoutObservable<string>;
    lastname: KnockoutObservable<string>;

    constructor(firstname: string, lastname: string) {
        this.firstname = ko.observable(firstname);
        this.lastname = ko.observable(lastname);
    }
}

ko.applyBindings(new MyViewModel("Jakob", "Christensen"));

Now if you build your project in VS, you will see a new folder underneath “wwwroot/build” with the compiled .js file.

Set up the webpack TypeScript load
Instead of letting VS do the TypeScript build we want webpack to do it and we already installed ts-loader to do it for us. Why would we want to do that now that VS can do it for us? I like to do it because I prefer to keep everything front-end-ish together. So, webpack does the build, the bundling, the code splitting, etc.

Now, add a file called webpack.config.js to your project at the project root. Paste the following into the file.

var path = require('path');

module.exports = {
    entry: {
        site: [
            './wwwroot/js/site.js', 
            './scripts/myviewmodel.ts']
    },
    output: {
        filename: 'bundle.js',
        path: path.resolve(__dirname, 'wwwroot/dist/')
    },
    module: {
        rules: [
            {
                test: /\.tsx?$/,
                loader: 'ts-loader',
                exclude: /node_modules/,
            },
        ]
    },
    resolve: {
        extensions: [".tsx", ".ts", ".js"]
    }
};

This configures webpack to compile the .ts files. It also instructs webpack to take the compiled .js file and bundle it together with some other site.js file that we might have in our project and put it all into a file called bundle.js places in “wwwroot/dist”. This is the file you want to reference in your HTML files. By the way, the compiled .js files will no longer end up in the “wwwroot/build” folder so you can delete that.

Webpack build
To build and bundle, first edit your package.json so that the build block looks like this.

  "scripts": {
    "build": "webpack"
  },

Then remove the line containing “compileOnSave” from tsconfig.json.

Finally, go to the cmd prompt and run the following npm command from your project folder.

npm run build

You should now see the file bundle.js in “wwwroot/dist”.

Of course you don’t want to go to the cmd prompt every time you have changed something in your .ts files, so we want VS to run the npm build. Fortunately, the ever-present Mads Kristensen has created a VS extension that does it for you. After installing the extension you can see the npm custom build task in Visual Studio’s Task Runner Explorer. Right-click “build” to tell VS to run the build task before or after your normal VS build.

This will add a line to the package.json file.

"-vs-binding":{"BeforeBuild":["build"]}

Cleaning up
As I said above, VS automatically picks up .ts files and builds. You don’t want that when using webpack. To disable the VS build, right-click your project in Solution Explorer and choose “Edit [your project name].csproj”. Add the following line under the <PropertyGroup> element.

<PropertyGroup>
    <!-- ... -->
    <TypeScriptCompileBlocked>true</TypeScriptCompileBlocked>
</PropertyGroup>

Also, you might want to remove bower.json and bundleconfig.json if present, as package.json and webpack.config.js replace them. As far as I know bundleconfig.json works with another Mads Kristensen extension to bundle .js files.

That’s it. Now it is up to you to take fully advantage of webpack for code splitting and uglifying and what not.

Setting up ASP.NET Core in Visual Studio 2017 with npm, webpack, and TypeScript: Part I

Example code on Github.

Things have been moving so fast in the last couple of years when it comes to web development.  The days of page refreshes on web sites are long gone.  The youngsters and hipsters want ajax, animations, spinners, and what not.  The JavaScript world has exploded with cool libraries and what is the newest, coolest, hottest library right now changes faster than I change my underwear (or maybe I’m just getting old, or I need to change my underwear more often).

Recently, Microsoft came out with the final release of Visual Studio 2017 (VS), and I figured now would be a good time to get my head around ASP.NET Core and all the cool JavaScript things.

The case in mind is a small intranet website that will allow the users to do some quick actuarial calculations.

Getting started
Let’s start by creating a Visual Studio ASP.NET Core project.  Start Visual Studio 2017 and create a new project from the “ASP.NET Core Web Application (.NET Framework)” template.  We will choose this template to make the code compatible with non-Core assemblies (the actuarial assemblies are compiled for .NET 4.5.2).

At the top of the dialog, choose which .NET framework you wish to be compatible with.

In the next dialog choose “Web Application”, and Visual Studio will set up a basic structure for your project.  Among other things, Visual Studio creates a folder named “wwwroot”.  This is where the files that will be published to the actual web server should be placed.  Don’t put anything else such as your code in that folder.

Setting up npm
To get all the JavaScript goodness into our project, we need to install the Node Package Manager (npm). As the name implies, npm is a package manager for JavaScript. Think Nuget for Javascript kind of thing. But npm can do more than that. It can also build TypeScript with the help of webpack which is what we will do later on.

You can install npm (Node.js) through the Visual Studio installer but you should always make sure that you are running the latest version. You can also download and install from the node.js web site.

Now we need to initialize node for our VS project directory. Open a command prompt and cd to the VS project folder (the folder where the .csproj file is located).

Run the command:

npm init -y

This will initialize npm for your project with default settings. The initialization creates a file named package.json. Notice how VS automatically recognizes the file and adds it to the web project.

You might want to open the package.json file and change the name attribute to all lower case since upper case letters are not supported (I have no idea why npm init does not change it to lower case while it is at it).

Run the following command to update npm at a later time.

npm install npm@latest

Installing webpack
Next up is webpack. Webpack seems to be the Swiss Army knife of JavaScript and it looks like people are moving from things like Grunt and Gulp to webpack. Also, in my humble opinion, the webpack documentation is far better than what you will se for a lot of the other “hot and cool” open source JavaScript libraries.

We will be using webpack for compiling TypeScript and for bundling script files.

Install webpack with npm by running the command

npm install webpack --save-dev

This will save webpack as a development (not production) dependency in package.json. We will be using webpack as part of the build process, hence the development dependency. The npm install command also creates a folder named “node_modules” in your project folder with dependencies. Do not include this folder in your project.

Next
In the next part of this series we will get up and running with TypeScript.