MySQL в cочетании с Entity Framework 4

14 мая 2011 г.

Вступление

При разработке архитектуры очередного проекта с нуля, заказчиком(программистом в прошлом) была поставлена задача в качестве СУБД использовать MySQL из-за «бесплатности» и наличия опыта работы с ней в качестве основных факторов. Основная платформа — .NET Framework 4.

В статье пойдет речь об выборе технологий и особенностях использования MySQL в cочетании с Entity Framework 4.

О проекте

Архитектурой проекта является типичная трехзвенка(Клиент- Веб-сервис- БД).
Основным должен стать «толстый» клиент, легким — тонкий(браузер).

Приложение представляет собой наличие большого количества бизнес логики при работе с таблицами, число которых в первой версии программы приближалось к 150. Проект также характеризуется минимальным для энтерпрайс решения бюджетом.

Задачи

Первой задачей было сделать выбор между использованием какой-то ОРМ или завязать всю логику общения с БД приложения на хранимых процедурах, используя чиcтый ADO.NET.
Задача, впрочем, не нова, опытные программисты, в зависимости от потребностей проекта, решают ее по разному.

Плюсы ОРМ

  • скорость разработки. Не надо писать большое количество хранимых процедур для реализации CRUD операций. Не надо писать замысловатые большие sql запросы.
  • использование языковых возможностей основной платформы. Другими словами не надо осваивать язык и особенности написания ХП. Яркий пример отсутствие готовой, простой реализации пейджинга в T-SQL.
  • упрощение автоматического тестирования

Минусы ОРМ

  • скорость выполнения. Можно сколько угодно говорить про различные уровни настройки ОРМ, кеша, но в любом случае ОРМ — посредник при передаче данных. Многие программисты работают по результату, не зная про планы запросов и их оптимизацию, что приводит к неизбежным задержкам выполнения. Где-то это выливается в сотые секунды, а где-то сильно заметно.
  • безопасность. Когда, вся логика общения с БД лежит в ХП, доступ к ней получить гораздо труднее, чем изменить готовую сборку, лежащую в открытом доступе или случайно неправильно обновить код, применительно к веб-разработчикам.
  • поддержка. Гораздо проще обновить функциональность в одном месте, чем делать это для каждого «толстого» клиента
  • сложность маппинга для нетривиальных сценариев.
  • надежность. Клиент-ориентированные транзакции могут решить больший объем задач по сравнению с серверными аналогами, но являются менее рекомендуемыми в плане надежности.

Я осознанно не упомянул некоторые субъективные факторы, такие как Запрет организаций на использование ОРМ, желание использовать что-то новое или идти проверенным путем и другие.

Субъективно мой выбор пал на использование ОРМ во многом благодаря фактору «скорость разработки», который является критичным для этого проекта.

Второй задачей был выбор ОРМ.
Выбора, как оказалось, большого нет.
Я по характеру своему консерватор, люблю использовать проверенные решения. Поэтому выбирал между .NHibernate и EntityFramework 4.

Выбор пал на EF 4.0, потому что
1) нативная MS технология
2) сильно улучшилась в 4 версии
3) инсайдер в Микрософте, который занимается разработкой VS сообщил мне, что EF будет 100% развиваться дальше
4) хорошо показала себя на составленном мной простом прототипе в связке с MySQL .NET провайдером
5) содержит приблизительно такие же возможности + много другого

Также был взят за основу принцип DB first и автоматическое подтягивание изменений маппинга из-за желания иметь всегда актуальную наглядную структуру БД, завязанную с кодом.

Текущий полет

Скорость имплементации слоя работы с БД по сравнению с написанием хранимых процедур увеличилась в разы.

Возникшие проблемы и их решение

  1. Основной проблемой EF 4 на сегодняшний день является использование для маппинга одного большого файла или 3, но без визуального отображения структуры данных. Это признают даже разработчики микрософт. Когда-то даже видел анонс по поиску умного алгоритма и разработчика для этой фичи.

    Решение
    Понимание структуры данных, корректный мерджинг изменений.

  2. Неприятный сюрприз преподнес MySQL.
    Оказывается группировка на клиенте у них не работает use " group by" statement in ado.net enetiy framework
    Особенно удивляет статус этого бага как не критический. А может и правда, группирование данных в контексте агрегатных функций это не модно…

    Решение
    Решение состоит в использовании хранимых процедур для таких особых случаев. К счастью, ХП, видимо, писала другая команда.

  3. И еще неприятный сюрприз опять же таки от MySQL.
    При автоматическом подтягивании схемы БД, видны ХП, но не видны их параметры.
    No parameters from stored procedures when using ADO .NET Data Entities

    Решение
    Корректный мерджинг изменений.

P.S.: Буду признателен за содержательные комменты, особенно в стиле Проблема-Решение

Теги: рубрика Сайтостроение