Куда проваливаются ОРМ?

Question

Я часто слышу, как люди ругают ORM за их негибкость и «утечку абстракций», но вы действительно не слышите , почему они проблематичны При правильном использовании, что именно являются неисправностями ORM? Я спрашиваю об этом, потому что я работаю над PHP-формой и хочу, чтобы она решала проблемы, с которыми не справляются многие другие ORM, такие как отложенная загрузка и отсутствие подзапросов.

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

Answer 1

Одна из самых больших проблем, которые я заметил со всеми ORM, которые я использовал, - это обновление только нескольких полей без предварительного извлечения объекта.

Например, скажем, у меня есть объект Project, сопоставленный в моей базе данных со следующими полями: Id, name, description, owning_user. Скажем, через ajax я хочу просто обновить поле описания. В большинстве ORM единственный способ для меня обновить таблицу базы данных, имея только значения Id и description, - это либо извлечь объект проекта из базы данных, установить описание и затем отправить объект обратно в базу данных (таким образом, требуя две операции базы данных только для одного простого обновления) или для обновления с помощью хранимых процедур (это метод, который я сейчас использую).

Answer 2

Объекты и записи базы данных на самом деле не так уж похожи. Они набрали слоты, в которых можно хранить вещи, но это все. Базы данных имеют совершенно другое понятие идентичности, чем языки программирования. Они не могут хорошо обрабатывать составные объекты, поэтому вы должны использовать дополнительные таблицы и внешние ключи. У большинства нет понятия наследования типов. А естественный способ навигации по сети объектов (следуйте некоторым указателям в одном объекте, получить другой объект и снова разыменовывать) гораздо менее эффективен при сопоставлении с миром баз данных, поскольку вам приходится совершать многократные обходы и извлекать партии данных, которые вас не волнуют.

Другими словами: абстракция не может быть очень хорошей во-первых; это не инструменты ORM, а метафора, которую они реализуют. Вместо идеального изоморфизма это лишь поверхностное сходство, поэтому сама задача не очень хорошая абстракция. (Тем не менее, это все же намного полезнее, чем глубокое понимание баз данных. Презрение к инструментам ORM происходит в основном от администраторов баз данных, которые смотрят свысока на простых программистов.)

Answer 3

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

Я думаю, что моя самая большая проблема с ними заключается в том, что, абстрагируя детали, младшие программисты получают меньше понимания того, как писать запросы, которые им необходимо уметь обрабатывать в крайних случаях и местах, где ORM пишет действительно. плохой код Очень сложно научиться продвинутым вещам, когда тебе никогда не приходилось понимать основы. ORM в руках кого-то, кто понимает объединения и групповые и продвинутые запросы, это хорошая вещь. В руках кого-то, кто не понимает булеву алгебру и объединения и кучу других базовых понятий SQL, это очень плохо, что приводит к очень плохому дизайну базы данных и запросов.

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

Answer 4

То, как я это вижу, таково. Чтобы использовать ORM, вам обычно нужно сложить несколько функций php, а затем подключиться к базе данных и, по сути, по-прежнему выполнять запрос MySQL или что-то подобное.

Почему вся абстракция между кодом и базой данных? Почему мы не можем просто использовать то, что мы уже знаем? Обычно веб-разработчик знает свой язык бэкэнда, язык БД (своего рода SQL) и некоторые языки внешнего интерфейса, такие как html, css, js и т. Д. *

По сути, мы пытаемся добавить слой абстракции, который включает в себя много функций (и мы все знаем, что функции php могут быть медленнее, чем присвоение переменной). Да, это микро расчет, но все равно он складывается.

Мало того, что теперь у нас есть несколько функций, которые мы должны выполнить, мы также должны изучить, как работает ORM, так что там есть некоторое время, потраченное впустую. Я думал, что вся идея разделения кода состояла в том, чтобы держать ваш код отдельно на всех уровнях. Если вы находитесь в мире LAMP, просто создайте свой запрос (вы должны знать MySQL) и используйте уже существующие функции php для подготовленных операторов. СДЕЛАНО!

ПУТЬ ЛАМПЫ:

• создать запрос (строка);
• использовать подготовленные mysqli операторы и извлекать данные в массив.

ORM WAY:

• запустить функцию, которая получает сущность
• , который выполняет запрос MySQL
• запустить другую функцию, которая добавляет условную
• запустить другую функцию, которая добавляет еще одну условную
• запустить другую функцию, которая присоединяется
• запустить другую функцию, которая добавляет условные выражения при объединении
• запустить другую функцию, которая готовит
• выполняет другой запрос MySQL
• запустить другую функцию, которая извлекает данные
• запускает еще один MySQL Query

У кого-нибудь еще есть проблемы со стеком ORM? Почему мы становимся такими ленивыми разработчиками? Или настолько креативно, что мы вредим нашему коду? Если это не сломано, не исправляйте это. В свою очередь, исправьте вашу команду разработчиков, чтобы понять основы веб-разработки.

Answer 5

ОРМ пытаются решить очень сложную проблему. Существуют крайние случаи изобилия и основные компромиссы дизайна без четких или очевидных решений. Когда вы оптимизируете проект ORM для ситуации A, вы по своей сути делаете его неловким для решения ситуации B.

Существуют ORM, которые обрабатывают ленивую загрузку и подзапросы «достаточно хорошо», но от «достаточно хорошо» до «отлично» почти невозможно перейти.

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

Я не смотрю на ORM как на негибкие и не более утонченные, чем ваша средняя сложная абстракция. Тем не менее, некоторые ORM лучше, чем другие в этом отношении.

Удачи в изобретении колеса.