Кто должен обрабатывать условия в сложных запросах, средство отображения данных или уровень обслуживания?

_{Шаблон data mapper сообщает вам только то, что он должен делать, а не то, как это должно быть реализовано.
Поэтому все ответы в этой теме следует рассматривать как субъективные, поскольку они отражают личные предпочтения каждого автора.}

Я обычно стараюсь, чтобы интерфейс картографа был как можно проще:

• fetch(), извлекает данные из объекта домена или коллекции,
• save(), сохраняет (обновляет существующие или вставляет новые) объект домена или коллекцию
• remove(), удаляет объект домена или коллекцию с носителя

Я сохраняю условие в самом доменном объекте:

$user = new User;
$user->setName( 'Jedediah' );

$mapper = new UserMapper;
$mapper->fetch( $user );

if ( $user->getFlags() > 5  )
{
    $user->setStatus( User::STATUS_LOCKED );
}

$mapper->save( $user );

Таким образом, у вас может быть несколько условий для поиска, сохраняя при этом интерфейс чистым.

Обратной стороной этого может быть то, что вам понадобится общедоступный метод для получения информации из объекта домена, чтобы иметь такой fetch() метод, но он вам все равно понадобится для выполнения save().

Не существует реального способа реализовать эмпирическое правило «Скажи, не спрашивай» для взаимодействия сопоставителя и объекта домена.

Что касается «Как убедиться, что вам действительно нужно сохранить объект домена?», который может прийти вам в голову, он был рассмотрен здесь, с подробными примерами кода и некоторыми полезными сведениями в комментариях.

Обновлять

В моем случае, если вы планируете работать с группами объектов, вам следует иметь дело с разными структурами, а не с простыми объектами домена.

$category = new Category;
$category->setTitle( 'privacy' );

$list = new ArticleCollection;

$list->setCondition( $category );
$list->setDateRange( mktime( 0, 0, 0, 12, 9, 2001) );
// it would make sense, if unset second value for range of dates 
// would default to NOW() in mapper

$mapper = new ArticleCollectionMapper;
$mapper->fetch( $list );

foreach ( $list as $article )
{
    $article->setFlag( Article::STATUS_REMOVED );
}

$mapper->store( $list );

В этом случае коллекция представляет собой прославленный массив с возможностью принимать различные параметры, которые затем используются в качестве условий для сопоставителя. Он также должен позволить сопоставителю получить список измененных объектов домена из этой коллекции, когда сопоставитель пытается сохранить коллекцию.

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

_{Примечание. В некотором смысле можно сказать, что средство сопоставления связано с шаблонами строителя / фабрики. Цель другая, но подход к решению проблем очень похож.}

Обычно я предпочитаю быть более конкретным, например:

BookDataMapper->getByAuthorAndPublisher($author, $publisher)

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

Если вы сделаете это более динамичным, вы легко можете иметь тенденцию предлагать слишком много функций через интерфейс. Фигово.

И взгляните на свое приложение. Вы увидите, что других запросов не так уж и много. Для основной части данных это обычно около 5-10 процедур, если они вообще есть. Он написан намного быстрее, чем даже думать о какой-то динамической системе, которая в любом случае действительно будет принадлежать ее собственному слою.