Шаблоны проектирования доступа к данным PHP для дополнения ORM

Question

В настоящее время у меня есть сайт, который зависит от шаблона Active Record с использованием Doctrine ORM в PHP. Я, как правило, поклонник этого подхода - он очень прост и хорошо подходит для управления простыми приложениями CRUD. Но по мере роста этого сайта я думаю, что моя потребность в более надежной функциональности домена также возрастет. Мне было интересно, какие другие типы шаблонов проектирования данных хорошо работают в сочетании с ORM.

Моя основная проблема сейчас заключается в том, что Doctrine, кажется, лучше всего работает как причудливый язык запросов, поэтому мои модели изобилуют такими методами:

function getBySomeClassfication($classification)
{
    return Doctrine_Query::create()
              ->select('stuff')
              ->from('ModelClass')
              ->where('something = ?', $classification)
              ->execute();
}

или если я хочу получить доступ к классу модели напрямую:

Doctrine::getTable('ModelClass')->findAll();

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

Я просто не совсем уверен, каков наилучший подход. Я чувствую, что ORM - отличный слой для запросов к отдельным таблицам и работы с отношениями. Но я хотел бы иметь больше гибкости при создании объектов домена, которые работают с несколькими моделями / таблицами.

Я прочитал об использовании шаблона Repository, но все еще имею несколько колебаний:

1. Я не хочу просто создавать бессмысленный слой абстракции, который просто раздувает исходную проблему.

2. Я не хочу заново создавать или делать бесполезным весь смысл использования Active Record ORM.

Есть мысли или предложения?

Answer 1

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

Иногда я вообще не вижу смысла в необходимости иметь дело со спецификой базы данных (например, одна сущность домена распространяется на несколько таблиц) при использовании ORM в качестве инструмента (с нуля) разработки объектно-ориентированной доменной модели. Недавно я ответил на более специфический для Java вопрос здесь , но, возможно, это поможет вам и для идеи архитектуры.

Answer 2

Вы можете взглянуть на реализацию Zend Framework ORM (если вы этого еще не сделали), где также можно определить отношения между несколькими таблицами .

Надеюсь, это поможет.