F# type providers vs C# interfaces + Entity Framework : <p>The question is very technical, and it sits deeply between F# / C# differences. It is quite likely that I might’ve missed something. If you find a conceptual error, please, comment and I will update the question.</p>

<p>Let’s start from C# world. Suppose that I have a simple business object, call it <code>Person</code> (but, please, keep in mind that there are 100+ objects far more complicated than that in the business domain that we work with):</p>

<pre><code>public class Person : IPerson
{
    public int PersonId { get; set; }
    public string Name { get; set; }
    public string LastName { get; set; }
}
</code></pre>

<p>and I use DI / IOC and so that I never actually pass a <code>Person</code> around. Rather, I would always use an interface (mentioned above), call it <code>IPerson</code>:</p>

<pre><code>public interface IPerson
{
    int PersonId { get; set; }
    string Name { get; set; }
    string LastName { get; set; }
}
</code></pre>

<p>The business requirement is that the person can be serialized to / deserialized from the database. Let’s say that I choose to use Entity Framework for that, but the actual implementation seems irrelevant to the question. At this point I have an option to introduce “database” related class(es), e.g. <code>EFPerson</code>:</p>

<pre><code>public class EFPerson : IPerson
{
    public int PersonId { get; set; }
    public string Name { get; set; }
    public string LastName { get; set; }
}
</code></pre>

<p>along with the relevant database related attributes and code, which I will skip for brevity, and then use Reflection to copy properties of <code>IPerson</code> interface between <code>Person</code> and <code>EFPerson</code> OR just use <code>EFPerson</code> (passed as <code>IPerson</code>) directly OR do something else. This is fairly irrelevant, as the consumers will always see <code>IPerson</code> and so the implementation can be changed at any time without the consumers knowing anything about it. </p>

<p>If I need to add a property, then I would update the interface <code>IPerson</code> first (let’s say I add a property <code>DateTime DateOfBirth { get; set; }</code>) and then the compiler will tell me what to fix. However, if I remove the property from the interface (let’s say that I no longer need <code>LastName</code>), then the compiler won’t help me. However, I can write a Reflection-based test, which would ensure that the properties of <code>IPerson</code>, <code>Person</code>, <code>EFPerson</code>, etc. are identical. This is not really needed, but it can be done and then it will work like magic (and yes, we do have such tests and they do work like magic).</p>

<p>Now, let’s get to F# world. Here we have the type providers, which completely remove the need to create database objects in the code: they are created automatically by the type providers! </p>

<p>Cool! But is it?</p>

<p>First, somebody has to create / update the database objects and if there is more than one developer involved, then it is natural that the database may and will be upgraded / downgraded in different branches. So far, from my experience, this is an extreme pain on the neck when F# type providers are involved. Even if C# EF Code First is used to handle migrations, some “extensive shaman dancing” is required to make F# type providers “happy”.</p>

<p>Second, everything is immutable in F# world by default (unless we make it mutable), so we clearly don’t want to pass mutable database objects upstream. Which means that once we load a mutable row from the database, we want to convert it into a “native” F# immutable structure as soon as possible so that to work only with pure functions upstream. After all, using pure functions decreases the number of required tests in, I guess, 5 – 50 times, depending on the domain. </p>

<p>Let’s get back to our <code>Person</code>. I will skip any possible re-mapping for now (e.g. database integer into F# DU case and similar stuff). So, our F# <code>Person</code> would look like that:</p>

<pre><code>type Person =
    {
        personId : int
        name : string
        lastName : string
    }
</code></pre>

<p>So, if “tomorrow” I need to add <code>dateOfBirth : DateTime</code> to this type, then the compiler will tell me about all places where this needs to be fixed. This is great because C# compiler will not tell me where I need to add that date of birth, … except the database. The F# compiler will not tell me that I need to go and add a database column to the table <code>Person</code>. However, in C#, since I would have to update the interface first, the compiler will tell me which objects must be fixed, including the database one(s).</p>

<p>Apparently, I want the best from both worlds in F#. And while this can be achieved using interfaces, it just does not feel the F# way. After all, the analog of DI / IOC is done very differently in F# and it is usually achieved by passing functions rather than interfaces.</p>

<p>So, here are two questions.</p>

<ol>
<li><p>How can I easily manage database up / down migrations in F# world? And, to start from, what is the proper way to actually do the database migrations in F# world when many developers are involved?</p></li>
<li><p>What is the F# way to achieve “the best of C# world” as described above: when I update F# type <code>Person</code> and then fix all places where I need to add / remove properties to the record, what would be the most appropriate F# way to “fail” either at compile time or at least at test time when I have not updated the database to match the business object(s)?</p></li>
</ol>
