Doctrine ORM *

Несмотря на то, что внедрение зависимостей в сущности считается плохой практикой с точки зрения DDD, существуют ситуации в которых это очень удобно. Правомерность использования такого подхода, а ровно как и сравнение его с альтернативами (двойная диспетчеризация, события) не является темой данной статьи. Я хочу рассказать о технической реализации — об интеграции Symfony Dependency Injection Component (далее DIC) с Doctrine для автоматического внедрения зависимостей в загружаемые сущности. Используемые версии Symfony и Doctrine — 2.*.

ViMbAdmin

ViMbAdmin проект (vim/-be/-admin/) предоставляет веб-интерфейс администрирования виртуальных
почтовых ящиков, позволяя почтовым администраторам легко управлять доменами, и псевдонимами.
ViMbAdmin является свободным программным обеспечением, вы можете распространять или изменять его в соответствии с условиями GNU General Public License версии 3.

ViMbAdmin был написан на PHP с использованием нашего собственного web application framework, который включает Zend Framework, ORM Doctrina и система шаблонов Smarty с JQuery и Bootstrap.

ViMbAdmin размещается на отдельной странице проекта GitHub, где можно найти документацию,
просмотреть исходный код. GitHub

UPDATE:

yum install dovecot-mysql

С момента релиза php 5.4 уже прошло некоторое время, и мы решили поэкспериментировать с трейтами (traits), оценить их практическое применение. Как их можно использовать вместе с объектами Doctrine2?

Трейты

Трейты в php — это набор свойств и методов, которые можно добавить в класс.
Они реализованы на уровне интерпретатора и являются абсолютно прозрачными для Doctrine.

Трейты спроектированы для горизонтального повторного использования и идеально подходят для добавления общего поведения в несколько объектов.

На днях я столкнулся со странной ошибкой в работе Doctrine2(версия 2.2.2).

Суть проблемы

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

В большинстве случаев стандартные методы, генерируемые доктриной на основе Yaml (XML или аннотаций), хватает только на получение каких то полей по какому-то простому фильтру. Для более сложного запроса приходиться пользоваться нативным QueryBuilder'ом и обращаться через dql запросы к нашей модели. Все это является следствием нагромождения больших кусков кода, которые имеют свойства дублироваться там где требуется применить идентичные запросы. А как хотелось бы обращаться с моделью просто и красиво через один единственный метод? Как? Напишем свой!

Предыстория

Не так давно, в связи с производственной необходимостью, я познакомился с замечательным фреймворком Symfony 2, в котором для работы с базой данных используется мощная популярная библиотека — Doctrine 2, включающая в себя два компонента: ORM (Object relational mapper) и DBAL (Database Abstraction Layer). ORM предоставляет приложению возможность общаться с базой данных на языке объектов, а DBAL, в свою очередь, представляет собой более низкоуровневый способ доступа к данным посредством написания запросов, основанный на php-библиотеке PDO. ORM предоставляет множество преимуществ при разработке сложных бизнес-приложений, но в то же время налагает и ряд ограничений, связанных с тем, что разработчику не приходится писать непосредственно SQL-запросы — ORM Doctrine предлагает свой собственный, объектно-ориентированный язык запросов, который преобразуется в привычный SQL уже за кадром. С одним из таких ограничений я и столкнулся, и хочу поделиться, каким образом я его успешно преодолел. Речь пойдёт о получении общего количества записей, возвращаемых запросом, если убрать из него ограничение LIMIT.

Интересная реализация для импорта данных в базу, так как можно вставлять данные в связанные таблицы. Автор тестировал код только на MySQL сервере и по его словах все работает на ура.
Вот собственно ссылка на статью

P.S. пишу топик, так как не хватает кармы чтобы сделать ссылку

Недавно стал пользоваться программой MySQL Workbench. Приложение меня очень порадовало, в нем очень удобно проектировать структуру базы данных, которую затем можно легко экспортировать на сервер Баз Данных (Forward Engineering). Так же можно использовать обратную разработку (Reverse Engineering): создание ER диаграммы по существующей структуре Базы Данных. Кроме того, в приложении есть синхронизация модели и существующей БД, что тоже очень удобно при разработке.

Но так как мы разрабатываем наши продукты с использованием ORM Doctrine, то кроме структуры БД необходимо было создать модели для доступа к данным. Как оказалось, что для Workbench есть дополнение, которое создает Doctrine YAML сразу из приложения. Немного поискав в инете, плагин был успешно найден. Страница разработчика находится вот здесь.

Используя данный плагин очень удобно и быстро можно создавать схемы для будущих моделей.

Эта статья посвящена точному(с учётом регистра) отображению названий колонок таблицы БД в свойства модели. Данная проблема актуальна для 1ой ветки ORM, т.к. во второй ветке она похоже уже решена. Но т.к. стабильным релизом на данный момент является версия 1.2.1 а версия 2 в стадии ALPHA4, то думаю, что эта проблема актуальная для многих пользователей ORM.

В прошлой статье я рассматривал один из способов быстрого доступа к переводимым атрибутам. Для того что бы понять о чем вообще идет речь, настоятельно рекомендуется прочитать укзаную статью перед этой ) Для тех, кто уже читал, напомню, что основной цимес состоял в искусственных гетерах и сетерах через hasAccessorMutator(), которые в свою очередь оверрайдились через __call()-функцию шаблона. Очевидный минус этого подхода это невозможность использовать __call() в других шаблонах, что не есть хорошо. Есть более красивый и эффективный способ реализовать такой доступ, причем он изначально был предусмотрен в Doctrine чуть ли не с самых первых версий — это фильтры атрибутов. И снова под катом много кода и текста.

Начиная от версии 4.0 в СУБД MySQL появилась достаточно удобная возможность подсчета количества всех подходящих под запрос записей, когда количество записей ограничивается LIMIT’ом. При работе с поиском в БД, а так же при выборках из таблиц с большим количеством записей такой функционал просто необходим. В этой статье я расскажу, как можно использовать эту возможность в ORM Doctrine

Я думаю многие со мной согласны, что Doctrine — один из самых мощных и удобных ORM для PHP, но с недавнего времени возможностей оного мне перестало хватать. Начнем с того что невозможно использовать ассоциации с условиями фильтрации, «волшебный» поиск с учетом перевода через I18n и много другого.

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

Начну с самого легкого — с расширения для мультиязычности Doctrine_Template_I18n. Оговорюсь сразу, текста будет много, как и много сумбурной технической информации

Довольно давно использую связку Zend Framework и Doctrine и очень не хватало сортировки для коллекций получаемых по ссылке. Оказалось, что это легко реализовать.

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