Какой у вас опыт работы с Doctrine ORM?

Я не эксперт в Doctrine - я только начал ее использовать, и я должен признать, что это немного неоднозначный опыт. Он многое для вас делает, но не всегда сразу понятно, как сказать ему сделать то или это.

Например, при попытке использовать файлы YAML с автоматическим обнаружением отношений отношение «многие ко многим» не транслировалось правильно в определение модели php. Никаких ошибок, как вы упомянули, потому что он вообще не рассматривал его как многие-ко-многим.

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

Я использую Doctrine в проекте среднего размера, где мне приходилось работать с уже существующими базами данных, которыми я не владею. Он дает вам множество встроенных функций, но у меня есть одна серьезная жалоба.

Поскольку мне приходилось генерировать свои модели из баз данных, а не наоборот, мои модели слишком близки к базе данных: поля имеют очень похожие имена на столбцы базы данных, чтобы получить объекты, которые вы должны запрашивать в том, что является важным sql (где поставить этот код и как его протестировать?) и т. д.

В конце концов, мне пришлось написать сложную оболочку для доктрины, которая заставляет меня задаться вопросом, не было бы проще просто использовать старый подход дао / модели и исключить доктрину из поля зрения. Жюри еще не решено. Удачи!

мы используем Propel с Symfony 2 года и Doctrine с Symfony более 1 года. Могу сказать, что переход на ORM с фреймворком MVC был лучшим шагом, который мы сделали. Я бы порекомендовал придерживаться Doctrine, хотя на то, чтобы научиться с ней работать, нужно время. В конце концов, вы найдете свой код более читабельным и гибким.

Если вы ищете место, с чего начать, я бы порекомендовал Symfony Jobeet tutorial http://www.symfony-project.org/jobeet/1_4/Doctrine/en/ (главы 3, 6 посвящены основам) и, конечно же, документацию Doctrine.

Как я уже писал выше, мы уже некоторое время используем Doctrine. Чтобы сделать нашу работу более удобной, мы разработали инструмент под названием ORM Designer (www.orm-designer.com), в котором вы можете определить модель БД в графическом пользовательском интерфейсе (больше никаких файлов YAML :-), что, кстати, совсем неплохо. ). Вы также можете найти там несколько полезных руководств.

Мой опыт похож на ваш. Я только начал использовать доктрину и никогда не использовал Propel. Однако я очень разочарован Доктриной. Это ужасная документация. Плохо организовано и довольно неполно.

У меня смешанные чувства. Я мастер SQL только потому, что его так легко проверить. Вы можете быстро тестировать операторы SELECT, пока не получите правильные результаты. А провести рефакторинг совсем несложно.

В Doctorine или любой другой ORM существует так много уровней абстракции, что это почти кажется ОКР (навязчивым / компульсивным). В моем последнем проекте, в котором я опробовал Doctrine, я наткнулся на несколько стен. Мне потребовались дни, чтобы найти решение для чего-то, что, как я знал, я мог бы написать на SQL за считанные минуты. Это так расстраивает.

Я сварливый. Сообщество по SQL ОГРОМНО. Сообщество / поддержка Doctrine незначительна. Конечно, вы могли бы взглянуть на источник и попытаться разобраться в нем ... и это проблемы, на решение которых уйдут дни.

Итог: не пробуйте Doctrine или какой-либо ORM, не запланировав много времени для самостоятельного грокинга.

Propel and Doctrine использует PDO. PDO имеет много открытых ошибок в Oracle Database. Все они связаны с полями CLOB. Помните об этом перед началом нового проекта, если вы работаете с Oracle. Ошибки открыты много лет назад. Doctrine и PDO будут аварийно завершены при работе с Oracle и CLOB

После некоторого исследования различных библиотек ORM для PHP я остановился на PHP ActiveRecord (см. phpactiverecord). Мое решение сводилось к минимальной конфигурации, легкости библиотеки и отсутствию генерации кода. Доктрина просто слишком сильна для того, что мне нужно; то, чего не делает PHP ActiveRecord, я могу реализовать в моем слое оболочки. Я бы посоветовал воспользоваться моментом и изучить ваши требования к ORM и посмотреть, предлагает ли простой, такой как PHP ActiveRecord, то, что вам нужно, или будет лучше реализована домашняя реализация активной записи.

Я думаю, что mtbikemike прекрасно резюмирует это: «Мне потребовалось несколько дней, чтобы найти решение для чего-то, что, как я знал, я мог бы написать на SQL за считанные минуты». Это тоже был мой опыт. SAD (медленная разработка приложений) гарантирована. Не говоря уже об уродливом коде и ограничениях за каждым углом. То, что должно занимать минуты, занимает дни, а то, что обычно было бы более сложным и занимало часы или дни, просто невыполнимо (или не стоит потраченного времени). Получающийся в результате код намного более подробный и загадочный (потому что нам действительно нужен другой язык запросов, DQL, чтобы сделать вещи еще менее удобочитаемыми). Странные ошибки встречаются повсюду, и большую часть времени они проводят, выслеживая их и сталкиваясь с ограничениями и проблемами. Доктрина (я использовал только v2.x) сродни бесполезному упражнению и абсолютно бесполезна. Это, безусловно, самый ненавистный компонент моей нынешней системы и действительно единственный, у которого есть огромные проблемы. Приступая к работе с новой системой, я всегда возвращаюсь от базы данных к классам сущностей, пытаясь выяснить, какое имя является правильным в разных местах кода. Полный кошмар.

Я не вижу ни одного плюса для Doctrine, только минусы. Я не знаю, почему он существует, и каждый день мне хочется, чтобы его не было (по крайней мере, в моих проектах).

Использование Doctrine 2.5 в 2015 году. Похоже, все шло хорошо. Пока я не захотел использовать две сущности (в JOIN). [теперь лучше после того, как я познакомился с DQL]

Хорошо:

• генерация SQL для меня
• использование внешних ключей и ссылочная целостность
• Генерация InnoDB по умолчанию
• обновления, внесенные в SQL с помощью инструмента командной строки doctrine

Хорошо:

• гипер-осведомленность об именовании и отображении, а также о том, как называть и как отображать сущности в фактические таблицы

Плохо

• занимает много времени - изучение кастомного API построителя запросов. Или выяснить, как сделать простое СОЕДИНЕНИЕ, интересно, есть ли лучшие методы ... Простые СОЕДИНЕНИЯ, кажется, требуют написания пользовательских функций, если вы хотите выполнять объектно-ориентированные запросы.
• [обновите первое впечатление выше] - я решил использовать DQL, так как он больше всего похож на SQL

Мне кажется, этот инструмент хорош по идее, но для его правильного выполнения требуется, чтобы разработчик потратил много времени на освоение. У меня возникает соблазн использовать его для генерации объектного SQL, но затем использовать PDO для фактического ввода / вывода. Только потому, что я еще не научился делать внешний ключ и ссылочную целостность с SQL. Но изучение этого кажется намного более простой задачей, чем изучение подробностей Doctrine даже с такими простыми вещами, как сущность, эквивалентная JOIN.

Доктрина в существующих проектах

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

Если бы я использовал его на существующих таблицах, я бы сначала ... очистил таблицы, что включает в себя:

• добавление столбца идентификатора, который является первичным / суррогатным ключом
• с использованием InnoDb / таблицы с поддержкой транзакций
• сопоставить его соответствующим образом с сущностью
• запустите инструмент проверки Doctrine (doctrine orm:validate-schema)

Это потому, что Doctrine делает определенные предположения о ваших таблицах. И потому что вы, по сути, собираетесь управлять своими таблицами с помощью кода. Таким образом, ваш код и ваши таблицы должны соответствовать как можно большему соотношению 1: 1. Таким образом, Doctrine не подходит для любых таблиц "произвольной формы" в целом.

Но тогда вы могли бы с некоторой осторожностью и в некоторых случаях уйти с мелочами, такими как дополнительные столбцы, не учитываемые в ваших сущностях (я не думаю, что Doctrine проверяет, если вы этого не попросите). Вам нужно будет построить свои запросы знание, что вам сходит с рук. т.е. когда вы запрашиваете «объект» в целом, Doctrine запрашивает все поля объекта, в частности, по имени столбца. Если ваша фактическая схема содержит больше имен столбцов, я не думаю, что Doctrine будет возражать (это не так, как я подтвердил, создав дополнительный столбец в моей схеме).

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

Использование Doctrine ORM в 2016 году с опытом работы ~ 2 - 2,5 года.

Внутренняя непоследовательность

SELECT i, p            
FROM \Entity\Item i
JOIN i.product p
WHERE ...

Предположим, что это Item и Product. Они связаны через Item.product_id с Product.id, а Product содержит Product.model, который мы хотим отображать вместе с Item.

Вот получение того же "product.model" из базы данных с использованием вышеуказанного SQL, но с различными параметрами SQL:

//SELECT i, p
$ret[0]->getProduct()->getModel();          

//SELECT i as item, p as product
$ret[0]['item']->getProduct()->getModel();  

//SELECT i as item, p.model as model
$ret[0]['model'];                           

Я хочу сказать следующее:

Структура Output ResultSet может кардинально измениться в зависимости от того, как вы пишете оператор DQL / ORM SELECT..

От массива объектов к массиву ассоциативного массива объектов, к массиву ассоциативного массива, в зависимости от того, как вы хотите SELECT. Представьте, что вам нужно внести изменения в свой SQL, а затем представить, что вам нужно вернуться к своему коду и заново выполнить весь код, связанный с чтением данных из набора результатов. Ой! Ой! Ой! Даже если это несколько строк кода, вы зависите от структуры набора результатов, нет полного стандарта развязки / общего стандарта.

В чем Доктрина хороша

В некотором смысле он устраняет необходимость в SQL, создании и обслуживании ваших собственных таблиц. Это не идеально. Иногда это терпит неудачу, и вам нужно перейти в командную строку MySQL и ввести SQL, чтобы настроить все до такой степени, чтобы Doctrine и вы были довольны, до которой Doctrine рассматривает типы столбцов как допустимые и где вы довольны типами столбцов. Вам не нужно определять свои собственные внешние ключи или индексы, это делается за вас автоматически.

В чем доктрина плохо

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

Последние мысли

Мне нравится Doctrine за создание / изменение таблиц для меня и за преобразование табличных данных в объекты и их сохранение обратно, а также за использование подготовленных операторов и других сдержек и противовесов, делающих мои данные более безопасными.

Мне нравится ощущение того, что Doctrine заботится о постоянном хранилище из объектно-ориентированного интерфейса PHP. У меня возникает болезненное ощущение, что я могу думать о своих данных как о части моего кода, а ORM позаботится о грязных вещах, связанных с взаимодействием с базой данных. База данных больше похожа на локальную переменную, и я понял, что если вы позаботитесь о своих данных, она вам ответит.

Я ненавижу Doctrine за ее непоследовательность и сложную кривую обучения, а также необходимость искать проприетарный синтаксис для DQL, когда я знаю, как писать что-то на SQL. Знания SQL легко доступны, у DQL нет такого количества экспертов в дикой природе, ни накопленных знаний (по сравнению с SQL), которые помогут вам, когда вы застряли.

На данный момент я использую фреймворк Symfony с Doctrine ORM, как насчет использования Doctrine вместе с простыми запросами? Например, из knpuniversity я могу создать собственный метод репозитория, например:

     public function countNumberPrintedForCategory(Category $category)
    {
        $conn = $this->getEntityManager()
            ->getConnection();
        $sql = '
            SELECT SUM(fc.numberPrinted) as fortunesPrinted, AVG(fc.numberPrinted) as fortunesAverage, cat.name
            FROM fortune_cookie fc
            INNER JOIN category cat ON cat.id = fc.category_id
            WHERE fc.category_id = :category
            ';
        $stmt = $conn->prepare($sql);
        $stmt->execute(array('category' => $category->getId()));
        return $stmt->fetch();
... lines 30 - 37
    }

Я просто использую Doctrine Entities, например, создание форм обработки, Когда мне нужен более сложный запрос, я просто делаю простой оператор и беру нужные мне значения. В этом примере я также могу передать Entity как переменную и взять ее значения для выполнения запроса. Я думаю, что это решение легко понять, и на создание форм уходит меньше времени, передача данных для них и написание сложных запросов не так сложно, как их написание с помощью Doctrine.

Немного поздно на вечеринку, но позволь мне бросить сюда свои два цента. Я буду подключаться к Laravel, потому что это фреймворк, который я использую.

Active Record против сопоставления данных против правильного ООП

Laravel и многие другие фреймворки любят Активная запись. Это может быть отличным вариантом для простых приложений и сэкономит ваше время на тривиальное управление БД. Однако с точки зрения ООП это чистый антипаттерн. SoC только что убили. Он создает связь между атрибутами модели и именами столбцов SQL. Ужасно для расширений и будущих обновлений.

По мере роста вашего проекта (и да, так оно и будет!) ActiveRecord будет доставлять все больше и больше боли. Даже не думайте легко обновлять структуру SQL. Помните, что имена столбцов присутствуют во всем коде PHP.

Меня наняли для проекта, цель которого в будущем стать довольно крупным. Я видел пределы ActiveRecord. Я просидел 3 недели и переписал все, используя Data Mapper, который отделяет БД от вышеперечисленных слоев.

Теперь вернемся к Картограф данных и почему я не выбрал Доктрину.

Основная идея Картограф данных заключается в том, что он отделяет вашу базу данных от вашего кода. И это правильный подход с точки зрения ООП. Правила SoC! Я подробно рассмотрел Доктрина, и сразу несколько нюансов не понравились.

• Отображение. Почему в мире кто-то может использовать комментарии как команды? Я считаю это крайне плохой практикой. Почему бы просто не использовать класс PHP для хранения отношений сопоставления?
• Ямл или XML для карты. Опять же, почему ?? Зачем тратить время на синтаксический анализ текстовых файлов, если можно использовать обычный класс PHP. Кроме того, класс может быть расширен, унаследован, может содержать методы, а не только данные. И т.п.
• Если у нас есть картограф и модель, передающая данные, то это должен быть картограф, хранящий модель. Такие методы, как $product->save(), просто не годятся. Модель обрабатывает данные, она не должна заботиться о сохранении чего-либо в БД. Это очень тесная связь. Если мы тратим время на создание картографа, то почему бы не иметь $mapper->save($product). По определению, картограф должен знать, как сохранять данные.

Такие инструменты, как Doctrine или Eloquent, несомненно, экономят время вначале. Но вот непростой вопрос для каждого индивидуально. Каков правильный компромисс между / временем разработки / будущими обновлениями / ценой / простотой / соблюдением принципов ООП /? В конце концов, вы должны ответить и принять правильное решение.

Мой собственный DataMapper вместо Doctrine

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

Вот основные принципы:

• Модель переносит данные, аналогично модели Laravel. Пример переменной $model для следующих примеров.
• ModelMap содержит поле, которое сопоставляет атрибуты модели со столбцами таблицы в базе данных SQL. ModelMaps знает имя таблицы, идентификатор и т. д. Он знает, какие атрибуты должны быть переданы в json, а какие атрибуты должны быть скрыты (например, deleted_at). Эта ModelMap содержит псевдонимы для столбцов с тем же именем (связанных таблиц). Пример переменной: $modelMap.
• ModelDataMapper - это класс, который принимает Модель и ModelMap в контроллере и предоставляет функции store / getById / deleteById. Вы просто звоните $modelMapper->store($model) и все.
• Базовый DataMapper также обрабатывает разбивку на страницы, возможность поиска, преобразование массивов в json, добавляет метки времени, проверяет мягкое удаление и т. д. Для простых целей достаточно базового DataMapper. Для чего-то более сложного его легко расширить с помощью наследования.