Почему всем так нужен Doctrine, если он много не умеет?

Работаю в компании, где юзается доктрина (2 версия). Если доктрина чего то не умеет, то запрос переписывается на plain SQL. Столкнулся с тем, что есть достаточно ограничений, доктрин не умеет IFNULL, полнотекстовый поиск MySQL хромает, механизм подзапросов не особо удобный, для работы с YEAR, Month и подобными стоковыми функциями mysql работает, только если что-то где то подкрутить в драйверах. Инсерт через persist, flush делает достаточное количество времени. Собственно, я думаю, что это не всё. Почему доктрину многие так восхваляют? Пока что я увидел сплошные минусы для себя.
  • Вопрос задан
  • 490 просмотров
Пригласить эксперта
Ответы на вопрос 5
usdglander
@usdglander
Yipee-ki-yay
Практически любая абстракция над чем бы то ни было - это всегда компромисс между скоростью работы и удобством сопровождения. Доктрина как и любая друга абстракция - это выбор в пользу скорости/удобства разработки с отказом от универсальности в запросах. В вашем проекте был сделан именно такой выбор, правильный или нет - не известно, но если проект уже работает и живёт (и приносит прибыль), то вряд ли этот инструмент заменят.

Почему доктрину многие так восхваляют?

Ни один профессионал (если он действительно профи) не будет говорить что вот "это круто", а остальное - говно. Ибо он понимает что каждый инструмент имеет свои плюсы и минусы и подходит для своих задач. Умение видеть этот баланс и есть профессионализм.
Ответ написан
@Flying
Doctrine реализует концептуально другой подход к работе с данными, именно в этом её большое преимущество и именно из этого следуют её ограничения.

Если вы когда-нибудь сталкивались с паттернами проектирования то, возможно, слышали о таком человеке как Мартин Фаулер и о его книге "Patterns of Enterprise Application Architecture". В ней описываются паттерны проектирования enterprise level приложений. В этой книге Фаулер предложил набор паттернов, организующих работу с источниками данных через представление этих данных в виде связанных между собой объектов. В этот набор входят Data Mapper, Identity Map, Unit of Work и множество других паттернов.

Если идти чуть глубже то суть Doctrine - это возможность работать с данными в базе данных как с обычными объектами. Если задуматься - это открывает невиданные перспективы в обеспечении предсказуемости разработки и поддержки кода проекта т.к. обеспечивает разработчика возможностью абстрагироваться от деталей хранения информации и сосредоточиться на важной части его работы - реализации бизнес-логики проекта. Doctrine же берёт на себя заботу о том чтобы приложение получило нужные данные когда ему это будет нужно, чтобы эти данные были корректно сохранены, чтобы не возникло конфликтов и т.д. и т.п.

Попробуйте представить себе большой бизнес-проект над которым работают множество людей, в котором есть сотни видов данных, взаимодействующих друг с другом и определены сложные процессы вовлекающие множество видов данных. Разумеется это все можно написать и поддерживать вручную, таких примеров много, вопрос в стоимости подобной работы. Представьте себе необходимость вручную описывать последовательность запросов для сохранения данных в 20 таблиц и необходимость поддерживать корректность этого кода при всех следующих изменений бизнес-требований проекта. Уверен, если после полугода подобной работы вам предложат заменить всё это на одну строку $em->flush() - вы с радостью согласитесь и, возможно, тогда поймёте что даёт Doctrine разработчику.

Именно из идеи перевода фокуса разработчика с деталей реализации хранилища данных на детали реализации бизнес-логики проекта рождаются ограничения Doctrine. Они могут восприниматься негативно если пытаться воспринимать Doctrine и DQL как урезанный SQL, почему-то возвращающий объекты, а не массивы. Да, разумеется какие-то сложные аналитические запросы вы на DQL не построите, но это только потому что у Doctrine другая цель. Если посмотреть на DQL чуть пристальнее (к примеру на то как в нём описываются join'ы) то можно заметить что Doctrine отталкивается не от того как данные разложены по таблицам, а от того как данные представлены в entities. Это не самое заметное, но очень важное отличие т.к. оно определяет пространство операций над данными. Грубо говоря приведённый вами ifnull() в DQL становится довольно бессмысленной конструкцией т.к. эта функция довольно слабо применима к объектам.

Разумеется в реальных проектах зачастую бывают задачи которые требуют работы с данными в базе данных за пределами Doctrine, это нормально, ни один инструмент не является всеобъемлющим. Однако описываемые вами "недостатки" Doctrine проистекают скорее от непонимания того что это за инструмент и зачем он нужен, какие задачи он призван решить. Это непонимание устраняется через изучение того с чем вы работаете на более глубоком уровне. Если вы решите устранить его - вы получите в свои руки один из лучших инструментов для работы с данными в бизнес-проектах который только есть в мире PHP и тогда, надеюсь, сможете оценить его по достоинству.
Ответ написан
Wolfnsex
@Wolfnsex
Если не хочешь быть первым - не вставай в очередь!
Работаю в компании где юзается доктрина (2 версия). Если конечно же доктрина чего то не умеет, то запрос переписывается на plain SQL.
Справедливости ради, я думаю стоит заметить, что ни один из известных мне ORM'ов - не умеет "всего", даже на уровне MySQL'а. А если говорить про более продвинутые БД (в плане функциональных возможностей), например, PostgreSQL - то ORM'ы вообще "мало чего умеют" (в процентном соотношении).

Собственно, я думаю, что это не всё.
Я более чем уверен, что это далеко не всё.

Почему доктрину многие так восхваляют? Пока что я увидел сплошные минусы для себя.
Я бы не был столь категоричным (минусы всё-таки не сплошные, какие-то плюсы в ней однозначно есть), но, на вопрос "почему?" лично я для себя сделал вывод, что основная популярность Doctrine - обусловлена тем, что она по умолчанию поставляется (или поставлялась) с Symfony, а Symfony в свою очередь основную популярность завоевала тем, что долгое время он(а) считалась самым сложным (или одним из самых сложных) PHP-фреймворков, с довольно высоким порогом вхождения, что в свою очередь возводило её в ранг некоего "идола", отличающего "опытного" разработчика от тех, кто в силу различных причин Symfony осилить не смог (или не захотел). Вот такая вот цепочка...

P.S. Всё выше написанное, является моим субъективным наблюдением, основанным на моём личном опыте работы со студентами и людьми повышающими свою квалификацию в ракурсе веб-разработок. Уважаемые коллеги, убедительно прошу вас не устраивать срач под этим постом, у меня к сожалению нет времени в достаточном количестве, что бы вести объективную дискуссию, а поддерживать перепалку - желания.
Ответ написан
@FanatPHP
Доктрина большая. Есть DBAL, есть квери билдер, есть ORM.

Конкретно мы используем в качестве ORM. Потому что работать с объектами удобно.
За удобство приходится платить.

Про "самый сложный фреймфорк" и "идола" - это, разумеется, детский лепет.
Ответ написан
@oxidmod
ОРМ не для выборок.
Разделите приложение на условно READ и WRITE части.

WRITE удобно через объекты, + реальная запись пойдет в базу батчами при вызове flush
Для READ ORM не нужен в принципе. Можно использовать простые QueryBuilder\DBAL\raw SQL
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы