Как расширить этот простой DataMapper?

Проблема ORM (несоответствие импеданса, как его называют) заключается именно в отношениях. В графе объектов (объекты в памяти) отношения являются указателями на другие объекты. В реляционной базе данных отношения меняются; Это делает невозможным простое сопоставление между двумя моделями, и поэтому ORM такие сложные.

Если вы хотите оставаться ближе к базе данных (избегая ORM), вам не следует пытаться абстрагироваться от отношений. Я пишу datamappers примерно так:

$car42 = $car_gateway->fetch(42);
$wheels = $wheel_gateway->selectByCar($car42);

В отличие от способа ORM:

$car42 = $car_gateway->fetch(42);
$wheels = $car42->selectWheels();

Это действительно означает, что шлюзы попадают в ваш клиентский код, но это также делает вещи очень прозрачными и близкими к базе данных.

Учитывая ваш ответ на ответ Тома, я бы порекомендовал вам взглянуть на что-то вроде Zend Framework. Его ORM имеет архитектуру типа «возьми или оставь», которая может быть реализована поэтапно.

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

Когда я начал разбираться в проблеме, я понял, что мне понадобится решение абстрактных проблем, которые можно было бы реализовать поэтапно, потому что они, очевидно, не собирались полностью переписывать. Мой первоначальный подход состоял в том, чтобы написать собственный ORM и DAL, которые сделают за меня всю тяжелую работу. Он отлично работал, потому что не вторгался в существующую кодовую базу, и поэтому позволил мне незаметно перенести целые части приложения на новую архитектуру.

Однако после переноса большой части пользовательской области нашего сайта в эту новую структуру и создания всего приложения на моей настраиваемой платформе (которая также включает настраиваемый интерфейсный контроллер и реализацию mvc), я переключаюсь на Zend Framework (это мой выбор, хотя я уверен, что некоторые другие фреймворки также будут работать в этой ситуации).

При переходе на Zend Framework у меня нет абсолютно никаких проблем с устаревшей базой кода, потому что:

• Я могу создавать новые модели и рефакторинг старые модели (построенные по моему кастому framework) ненавязчиво.
• Я могу провести рефакторинг существующего контроллеры (такие, как они есть), чтобы быть завернутый в класс, который ведет себя в манере, совместимой с Zend's Фреймворк MVC, чтобы он стал небольшая проблема, чтобы начать использовать Внешний контроллер Zend.
• Наши взгляды уже встроены Умный, так что мне не о чем беспокоиться о разделении контроллера и представления логика, но я смогу продлить Zend Framework, чтобы я мог рендеринг существующих шаблонов в Smarty при создании новых шаблонов в прямой PHP.

По сути, Zend Framework имеет архитектуру типа «возьми или оставь», которая доставляет удовольствие использовать в существующих проектах, потому что новый код и реорганизованный код не должны вторгаться в существующий код.

Если вы ищете простой и портативный ORM DataMapper, обратите внимание на phpDataMapper. Это только зависимости PHP5 и PDO, и он очень маленький и легкий. Он поддерживает отношения таблиц и некоторые другие очень приятные функции.