Ответы пользователя по тегу ORM
  • Выбор PHP ORM, ActiveRecord?

    Сначала, наверное, нужно оценить вам ActiveRecord или DataMapper — если второе, то у Doctrine 2 конкурентов вроде нет, даже если ограничиваться не только PHP. Если ActiveRecord то вариантов тьма. Включая первую Doctrine — я бы её в качестве AR выбрал, если б не смущало, что поддержка её вряд ли будет полноценной, а развития скорее всего вообще не будет.

    Кстати, спасибо, за то что дали повод заклянуть на сайт Doctrine и увидеть, что у них появился ODM не только для Mongo, но и для Couch (правда в альфе пока). Кстати, это ещё один плюс в сторону Doctrine 2 — больших изменений в коде не потребуется, если захотите перейти на Couch или Mongo.
    Ответ написан
  • Для чего нужна 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().
    Ответ написан
  • ORM для PHP

    Doctrine2 — первая тоже была хороша, но вторая сказка :) Модели обычные объекты, не наследники чего-нибудь — связь с базой задаётся или в конфигах, или в аннотациях (комментарии к классу и свойствам по типу phpdoc) — никакой двойной, а то и тройной ответственности, модель не знает как и где она хранится в принципе, никаких методов объекта save или класса find нет. За хранение (вернее «персистентность») объектов отвечают репозитории. В общем реализованы паттерны DataMapper и UnitOfWork, а не популярный ActiveRecord в разных вариациях.
    Ответ написан