Ответы пользователя по тегу Doctrine ORM
  • Doctrine migrations:diff генерирует каждый раз новые миграции?

    Потому что первая сгенерированная миграция не применялась. Генератор и сравнивает схему и маппинг, но он не смотрит на сгенерированные, но не примененные миграции. То есть между каждыми doctrine:migrations:diff обязательно должно быть doctrine:migrations:migrate. Или нужно удалять непримененные перед генерацией.
    Ответ написан
  • Как правильно реализовать модель в Symfony2 на базе MVC?

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

    Сервисы использую когда в методах различных сущностей появляется дублирование кода или просто непонятно к какой сущности отнести тот или иной метод — типичный пример: перевод со счёта на счёт, оба счёта в принципе равноправны, и что метод DebetTo в источнике, что метод CreditFrom в получателе будет выглядеть некрасиво, особенно если будет ещё и третий счёт, на который перечисляется комиссия за транзакцию, а создание класса транзакции в модели нецелесообразно — прямой кандидат в сервисы. Вообще сервисы рассматриваю как функции.
    Ответ написан
  • Для чего нужна ORM?

    Вы не путаете ORM с DBAL? ORM это не технология замены SELECT * FROM goods WHERE cost < 100.00 на $db->select()->from('goods')->where('cost < 100.00'). ORM это способ задания связи объектов и РСУБД. По сути позволяет абстрагироваться от способа хранения объектов вообще, с лёгкостью переходя от SQL к NoSQL, memcache, файлам или REST/RPC API на удалённом сервере, оперируя на уровне модели (если говорить о MVC и т. п.) простыми plain old objects, а их персистентность отдать контроллеру. Не $db->select()->from('goods'),, не mysql_query('SELECT * FROM goods'), а $goodsRepository->findAll(), а уж будет репозиторий формировать SQL запрос, читать файлы или память, а может стучаться на Гугл и парсить его вывод — его, репозитория, личное дело (а также разработчика(ов), отвечающих за подсистему хранения).

    Кроме того ORM, как правило не исключает обращение к БД на уровне произвольных SQL запросов, оно лишь преобразуют результаты этих запросов в объекты модели предметной области (и наоборот), которые ничего не знают (в идеале) о таблицах, WHERE, HAVING и т. п.

    ORM это не только инструмент архитектурного разделения областей ответственности объектов и классов приложения, а также инструмент облегчения разделения труда разработчиков: кто хорошо шарит в SQL вообще и особенностях конкретного движка в частности — работает по «ту сторону» ORM, оптимизирует его как хочет, может нормализовывать и денормализовывать, например; кто хорошо разбирается в дебетах и кредитах — работает с plain old objects в терминах предметной области и может вообще ничего не зная об SQL, ему лишь нужно знать, что он всегда может получить объект или их коллекцию обратившись к методам вроде findById() или findAll() и сохранить результат работы методом save() или flush().
    Ответ написан
  • PDO или ORM в PHP?

    По моему опыту, при тонкой настройке библиотек, реализующих ORM (прежде всего настройка lazy load чуть ли не для кждого запроса) оверхид при выполнении от них небольшой (по сравнению с собственно выполнением запроса) и полностью компенсируется упрощением разработки и поддержки, если не требуется использовать «экзотику» типа хранимых процедур или триггеров.
    Ответ написан
  • Испольование в одной таблице пары instance_id, instance_type в Doctrine

    Использую Doctrine ODM + MongoDB :)

    Если не подходит такой вариант рассмотрите возможность создания общего примарикей (возможно ещё какие-то поля будут общие) для инстансов, то есть вместо instance_id и instance_type в log хранится inctance_id, но он общий для двух таблиц и связь происходит либо непосредственно через него (тогда надо обеспечить уникальность id в обеих таблицах, простой автоинкремент не подойдёт), либо создать ещё одну таблицу с полями id (автоинкрементное, по которому связь идёт с log), instance1_id, instance2_id + другие общие поля. В общем паттерн «наследование с таблицами для каждого класса» (если не напутал).

    Как-то пробовал решать подобную задачу, но у меня число типов было неограниченно и одним SQL так и не смог её решить
    Ответ написан