serge_gorshkov


Сергей Горшков - о бизнесе в сфере ИТ

о семантической интеграции, программировании, управлении...


Previous Entry Share Next Entry
О пользе и вреде ORM
serge_gorshkov
На минувшем "Дне открытых дверей" нашей компании я открывал программу крайне полемичным докладом о том, способна ли ORM облегчить труд программиста, или только усложняет его и отучает думать. Тема, конечно, холиварная, и специально такой задумывалась: чтобы взбодрить публику и спровоцировать дискуссию. Особого обсуждения, правда, не получилось. У меня создалось впечатление, что народ бОльшей частью был "не в теме" (кроме программистов, много было SEOшников), а те, кто были в теме - частью согласились с моими выводами (что ничего хорошего в ORM, по крайней мере для бизнес-приложений, нет), частью просто решили отмолчаться. Анкеты, которые публика заполняла по ходу мероприятия, подтверждают эту мысль.
Чтобы труд все-таки был увековечен, выкладываю здесь презентацию от доклада, и его основные тезисы. В скором времени в нашем корпоративном блоге появится и видеозапись доклада.



Презентация доклада "ORM: зло или благо?"

ORM - это программная прослойка между приложением и базой данных, которая позволяет программисту работать с данными из базы так, как будто это объекты. Грубо говоря, вместо
    $s=“INSERT INTO clients SET name=‘Альфа’”;
    mysql_query ($s, $connid);
писать

    $client = new Client ();
    $client->setName ("Альфа");
    $client->persist ();

Считается, что ORM позволяют:
  • Сократить семантический провал между объектной и реляционной формой хранения данных.
  • Повысить скорость и снизить трудоемкость работы программиста (требуется меньше кода, который проще отлаживать).
  • Код, использующий ORM, меньше подвержен ошибкам.
Сложно спорить только с третьим утверждением. Наверное, и правда есть такие программисты, которые не совершают ошибок. Может быть, им помогает в этом ORM.

По первому вопросу я считаю, что:
  • Не всегда можно однозначно сопоставить класс и объект БД (например, в случае таблиц-связок нет нужды плодить отдельный объект для каждой связи).
  • Не представляя себе реальной структуры БД, программисту будет крайне сложно работать с базой рационально, и оптимизировать скорость работы.
  • Абстрагируясь от базы, мы практически исключаем возможность использования ее <продвинутых> средств, таких как хранимые процедуры, представления, триггеры.

Второе преимущество в сложных проектах сводится к нулю следующими факторами:
  • Ускорение работы программиста обычно приводит к замедлению работы продукта, что в конечном счете, с точки зрения экономики, окажется гораздо менее рационально.
  • Все случаи обращения к БД в сколько-нибудь сложном проекте все равно не охватываются стандартными возможностями ORM. В таких случаях применяются "костыли", которые, в конечном счете, замедляют работу программиста.
Чтобы перейти с теоретического уровня на практический, я смоделировал несложную структуру данных (заказы, товары, клиенты, связка заказы-товары), наполнил ее несколькими десятками тысяч записей, и проверил скорость формирования списка продаж (с суммой стоимости по каждой из них) шестью способами - тремя с использованием ORM (для теста использовалась Doctrine 2), и тремя - без. Что это были за способы, и какими оказались результаты - можно посмотреть в конце презентации.
Правда, у меня осталось ощущение, что чего-то я в Doctrine все-таки не понял. Например, чем занимается столько времени метод prepare(), который готовит к выполнению прямой запрос к БД. Публика на Дне открытых дверей не помогла мне на него ответить; если кто-то поможет пролить свет на этот вопрос, я буду рад.





  • 1
Из кулуарных разговоров с посетителями ДОД: один программист высказал мнение, что человек, рассказывавший про ОРМ, не в теме, не имеет большого опыта их использования, потому и отзывается так, "я использовал ОРМ, и не увидел описанных в докладе проблем".
Задала простой вопрос: вы когда-либо с триггерами, зранимыми процедурами работали. Ответ: нет.
- А какого рода запросы вообще выполнялись?
- Просто выборки из одной таблицы.
Что и требовалось доказать.
Каждой задаче свой инструмент. Когда речь идет не о забивании гвоздей - молоток плохой помощник. Несмотря на прозрачный интерфейс и удобную рукоятку.

Это продолжает мои прошлые рассуждения о программистах, которые не хотят программировать. Человек, который просто выполнял выборки из одной таблицы (и не хочет делать ничего более сложного), вряд ли может считаться программистом.

Кроме того, твой собеседник вообще говорил о продукте, реализующем паттерн ActiveRecord - это еще не ORM.

  • 1
?

Log in

No account? Create an account