История, написанная с опытом переноса кодовой базы .Net с SQL Server на поддержку нескольких баз данных.
Почему Миграция?
Для проектов на основе .Net SQL Server может быть не единственным выбором, когда речь идет о предприятии. Учитывая изменение лицензирования Microsoft с процессора на ядро в 2012 году, это больше не удобный вариант, и спрос на другие базы данных увеличился.
Это вынуждает многие корпоративные приложения поддерживать различные другие базы данных, которые предлагают отличные функции безопасности и варианты лицензирования.
Из-за возросшего спроса необходимо перейти на инфраструктуру объектно-реляционного сопоставления (ORM) или эквивалентную реализацию в зависимости от потребностей.
ORM или родные драйверы:
Реализация на основе собственного драйвера предполагает динамическое переключение/множество кодовых баз. Таким образом, поддержка новой базы данных может потребовать внесения изменений в кодовую базу.
Мы оценили две платформы ORM nHibernate и Entity Framework (EF6). Мы выбрали EF6, учитывая лучшую долгосрочную поддержку для предприятий.
В моем случае я выбрал EF6 с подходом Code First. Подход Code First позволяет нам избежать файлов конфигурации, специфичных для базы данных.
Результаты производительности (собственный поставщик SQL по сравнению с EF6 ORM):
- Тесты производительности выполняются на основных идентичных серверах.
- Инициализация ORM выполняется перед запуском теста производительности.
Преимущества:
- Поставщики EF от соответствующих владельцев БД — огромное преимущество.
- Скомпилированные запросы с LINQ (меньше неожиданностей во время выполнения)
- Нет ручных операторов SQL
- Автоматическая генерация запросов, безопасная для SQL-инъекций
Недостатки:
- Стоимость производительности в 2 раза выше, чем у ADO.NET без ORM. Это можно исправить с помощью нескольких оптимизаций, но это не соответствует нативной производительности.
- Нет контроля над генерацией запроса. Это приемлемо, пока поддержка со стороны провайдеров хороша. До сих пор Oracle, PostgreSQL и SQL Server кажутся очень активными и стабильными с последними выпусками.
Несмотря на то, что результаты производительности не внушают оптимизма, его функции для нескольких баз данных и тот факт, что мы можем придерживаться одной базы кода, побудили нас выбрать EF.
На что обратить внимание при миграции:
- В отличие от SQL-сервера, большинство других баз данных чувствительны к регистру для имен таблиц и имен столбцов. Чтобы преодолеть эти проблемы, мы решили создавать таблицы и столбцы, задав чувствительность к регистру так же, как в модели.
- Если ваше приложение использует проверку подлинности с помощью форм или аналогичную, которая требует собственных поставщиков. Эта часть должна быть переписана с помощью пользовательского поставщика.
- SQL-запросы свободного стиля должны быть преобразованы в LINQ. Больше никаких строковых запросов
- Скажите «нет» большинству хранимых процедур, поскольку такие базы данных, как PostgreSQL, их не поддерживают. Добавление определенных блоков заставит ваше приложение придерживаться меньшего количества баз данных.
- Для приложений .Net обычно используются отчеты на основе SSRS (написанные в RDL). В этом случае необходимо преобразовать все отчеты на основе RDL в отчеты RDLC.
Резюме:
По сути, EF6 имеет накладные расходы по сравнению с собственными драйверами. Но он предоставляет отличный способ кодирования с использованием LINQ и достижения переносимости базы данных. Кривая обучения EF6 минимальна для человека, знакомого с LINQ.
Удачного кодирования!