Каков ваш опыт работы с доктриной ORM?

Ответ 1

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

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

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

Нижняя строка: не пытайтесь использовать Doctrine или ORM, не планируя много времени для grokking самостоятельно.

Ответ 2

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

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

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

Ответ 3

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

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

Ответ 4

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

Ответ 5

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

Ответ 6

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

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

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

Ответ 7

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

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

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

Ответ 8

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

Ответ 9

Использование 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). Я не рекомендую использовать Doctrine для существующих таблиц, пока я не узнаю это лучше.

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

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

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

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

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

Ответ 10

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

В чем причина Doctrine в

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

Заключительные мысли

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

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

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

Ответ 11

В настоящее время я использую структуру 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.