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

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

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

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

Итог: не пробуйте Доктрину или любую ОРМ, не планируя много времени для grokking самостоятельно.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Хорошо:

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

Хорошо:

• гиперсознание наименования и сопоставления и как назвать и как сопоставить объекты в фактических таблицах

Плохо

• занимает много времени – изучение пользовательского API построителя запросов. Или выяснить, как сделать простой JOIN, задаваясь вопросом, есть ли лучшие методы там. Простые JOINs, похоже, требуют написания пользовательских функций, если вы хотите делать объектно-ориентированные запросы.
• [update on first impression above] – я решил использовать DQL, поскольку он больше похож на SQL

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

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

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

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

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

Это потому, что Doctrine делает определенные предположения о ваших таблицах. И потому, что вы по существу собираетесь управлять таблицами с помощью кода. Таким образом, ваш код и ваши таблицы должны быть в максимально возможном соотношении 1: 1. Таким образом, 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 к Item.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 для создания / модификации таблиц для меня и для преобразования табличных данных в объекты и их сохранения, а также для использования подготовленных операторов и других сдержек и противовесов, что делает мои данные более безопасными.

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

Я ненавижу Доктрину за ее несогласованности и жесткую кривую обучения, и мне приходится искать проприетарный синтаксис для 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.