Справочная информация: Я создаю инструмент C# переноса данных для перемещения данных из старого приложения (с SQL базой данных сервера) в наше новое приложение (также используя SQL базу данных сервера) , но я использую наш веб-API, а не выполняю прямые вставки в новую базу данных, чтобы повторно использовать бизнес-логи c и тому подобное. Я использую Entity Framework для чтения из устаревшей базы данных.
Проблема: Старая система баз данных по неизвестным мне причинам использует архивную таблицу в дополнение к таблице с последней версией версия записей. Например, может быть таблица «человек», а затем также таблица «a_person» с несколькими заархивированными копиями предыдущих записей. Я планирую хранить эти архивные записи в одной таблице, просто объединенные в цепочку в архитектуре на момент времени. Таким образом, это практически идентичные столбцы, но из-за EF6 это два разных объекта, что означает, что я удваиваю весь свой код, когда пытаюсь переместить значения из "person" и "a_person" в новейший объект данных, который будет отправлен в API. Если бы это был только один пример, ничего страшного, но есть около полдюжины таблиц, которые имеют этот шаблон.
Я пытаюсь придумать лучший способ справиться с этим. Сначала я думал о добавлении интерфейсов к сгенерированным классам EF6, например, semanti c sugar, чтобы разрешить переход к общему методу, но мне все равно нужно было бы вернуть его обратно к исходным классам, чтобы он мне ничего не купил.
Затем я решил сериализовать каждую из таблиц в строку json, которую я могу десериализовать в словарь, а затем иметь общий метод c, который будет извлекать мои значения. Однако мне кажется, что это может быть излишне медленным.
В последнее время я думаю о том, чтобы вернуться к своей первоначальной идее с интерфейсами, но с частичными классами для EF6, реализующими общий интерфейс, и реализацией, которая может вернуть разные значения родительского класса EF6. Таким образом, и «родительские», и «a_parent» сущности будут иметь частичные классы, которые реализуют интерфейс и возвращают все значения для родительского объекта. Опять же, это просто кажется более изящным способом дублировать мой код доступа к значениям.
Сериализация и десериализация кажутся единственным способом по-настоящему устранить дублирующийся код. Хотя продолжительность миграции не является критическим фактором, я бы предпочел не создавать максимально медленное sh решение. Думаю, есть еще Reflection. Будет ли Reflection предпочтительнее сериализации и десериализации?