Поставщики типов F# и интерфейсы C# + Entity Framework

Вопрос очень технический, и он лежит глубоко между различиями F# и C#. Вполне возможно, что я что-то упустил. Если вы обнаружите концептуальную ошибку, пожалуйста, прокомментируйте, и я обновлю вопрос.

Начнем с мира C#. Предположим, что у меня есть простой бизнес-объект, назовем его Person (но, пожалуйста, имейте в виду, что в той бизнес-области, с которой мы работаем, существует более 100+ объектов, намного более сложных):

public class Person : IPerson
{
    public int PersonId { get; set; }
    public string Name { get; set; }
    public string LastName { get; set; }
}

и я использую DI / IOC, поэтому я никогда не передаю Person. Скорее, я бы всегда использовал интерфейс (упомянутый выше), назовите его IPerson:

public interface IPerson
{
    int PersonId { get; set; }
    string Name { get; set; }
    string LastName { get; set; }
}

Бизнес-требование состоит в том, чтобы человека можно было сериализовать в/десериализовать из базы данных. Допустим, я решил использовать для этого Entity Framework, но фактическая реализация кажется не относящейся к вопросу. На данный момент у меня есть возможность ввести классы, связанные с «базой данных», например. EFPerson:

public class EFPerson : IPerson
{
    public int PersonId { get; set; }
    public string Name { get; set; }
    public string LastName { get; set; }
}

вместе с соответствующими атрибутами и кодом, связанным с базой данных, которые я пропущу для краткости, а затем используйте Reflection для копирования свойств интерфейса IPerson между Person и EFPerson ИЛИ просто используйте EFPerson (передается как IPerson) напрямую ИЛИ сделайте что-то еще. Это совершенно не имеет значения, так как потребители всегда будут видеть IPerson, и поэтому реализация может быть изменена в любое время, а потребители ничего об этом не знают.

Если мне нужно добавить свойство, то я сначала обновлю интерфейс IPerson (допустим, я добавлю свойство DateTime DateOfBirth { get; set; }), а потом компилятор подскажет, что исправить. Однако если я уберу свойство из интерфейса (допустим, LastName мне больше не нужен), то компилятор мне не поможет. Однако я могу написать тест на основе Reflection, который бы гарантировал идентичность свойств IPerson, Person, EFPerson и т. д. Это на самом деле не нужно, но это можно сделать, и тогда это будет работать как по волшебству (и да, у нас есть такие тесты, и они работают как по волшебству).

Теперь давайте перейдем к миру F#. Здесь у нас есть провайдеры типов, которые полностью избавляют от необходимости создавать объекты базы данных в коде: они создаются автоматически провайдерами типов!

Прохладный! Но так ли это?

Во-первых, кто-то должен создавать/обновлять объекты базы данных, и если задействовано более одного разработчика, то естественно, что база данных может и будет обновляться/понижаться в разных ветках. До сих пор, по моему опыту, это очень мучительно, когда задействованы поставщики типов F#. Даже если C# EF Code First используется для обработки миграций, требуются некоторые «обширные шаманские танцы», чтобы сделать поставщиков типов F# «счастливыми».

Во-вторых, в мире F# по умолчанию все неизменяемо (если только мы не сделаем его изменяемым), поэтому мы явно не хотим передавать изменяемые объекты базы данных вверх по течению. Это означает, что как только мы загрузим изменяемую строку из базы данных, мы хотим как можно быстрее преобразовать ее в «родную» неизменяемую структуру F#, чтобы работать только с чистыми функциями вышестоящего уровня. Ведь использование чистых функций уменьшает количество необходимых тестов, наверное, в 5-50 раз, в зависимости от предметной области.

Вернемся к нашему Person. Я пока пропущу любое возможное переназначение (например, целое число базы данных в случае F# DU и тому подобное). Итак, наш F# Person будет выглядеть так:

type Person =
    {
        personId : int
        name : string
        lastName : string
    }

Так вот, если «завтра» мне нужно добавить в этот тип dateOfBirth : DateTime, то компилятор мне расскажет обо всех местах, где это нужно исправить. Это здорово, потому что компилятор C# не скажет мне, куда мне нужно добавить эту дату рождения, … кроме базы данных. Компилятор F# не скажет мне, что мне нужно пойти и добавить столбец базы данных в таблицу Person. Однако в C#, поскольку мне пришлось бы сначала обновить интерфейс, компилятор сообщит мне, какие объекты должны быть исправлены, включая объекты базы данных.

Очевидно, я хочу получить лучшее от обоих миров в F#. И хотя этого можно добиться с помощью интерфейсов, это просто не похоже на F#. Ведь аналог DI/IOC в F# делается совсем по-другому и обычно достигается за счет передачи функций, а не интерфейсов.

Итак, вот два вопроса.

1. Как я могу легко управлять миграцией базы данных вверх/вниз в мире F#? И, для начала, как правильно выполнить миграцию базы данных в мире F#, когда задействовано много разработчиков?

2. Каков способ F# для достижения «лучшего из мира C#», как описано выше: когда я обновляю F#, набираю Person, а затем исправляю все места, где мне нужно добавить/удалить свойства в запись, что будет наиболее подходящим способом F# для «сбой» либо во время компиляции, либо, по крайней мере, во время тестирования, когда я не обновил базу данных, чтобы она соответствовала бизнес-объекту (объектам)?