Размышления о применимости DDD (Domain Driven Design) для веб проектов не дают покоя.
Сразу оговорюсь, что рассуждения касательно применимости не в энтерпрайз, а в своих мелких проектикиках.
Попробую систематизировать размышления, т.к. текущее состояние мыслей похоже на это в центральной стадии:
1. принцип DDD — проектируем модель, а затем думаем как сохранять. Хорошо, если модель легко проектируется на место хранения…
Возможно у меня кривое представление модели, но, под моделью(MVC, DDD) я понимаю большой жирный слой, в котором нужно реализовать следующее:
Интерфейсы, реализация классов объектов(геттеры, сеттеры). Связи между объектами пока опустим.
Обычно не сложно.
Сохранением объектов занимаются мапперы. Проектируем интерфейс маппера и реализуем по 1 мапперу на каждый класс объекта. Что-то простое плоское сохранять и извлекать легко. Идеологически, в коллекциях MongoDB правильно хранить агрегаты. Агрегаты — это сложные объекты, имеющие не плоскую структуру(состоящие из вложенных объектов). Для декомпозиции агрегатов нужен ещё один уровень абстракции. Назовём его Data Abstraction layer(DAL). Но о нём позже.
О реализации маппера, 2 варианта:
Оба варианта холиварные. Мне нравится второй, т.к. мапперы меняются не так часто(никогда) и получаем автокомплит.
Опять же удобно сделать MappersManager, который будет конструировать мапперов.
IdentityMap для объектов:
Неплохо бы кешировать объекты, чтобы при повторном обращении к мапперу получать данные из кеша, 2 варианта:
Мне нравится второй, т.к. в маппере могут быть самостоятельные обращения к IdentityMap.
Lazy Load конструирование данных:
При выборке большого количества объектов, маппер возвращает итератор над коллекцией, элементы которой будут созданы только в момент фактического доступа (foreach), 2 варианта:
Инвалидация IdentityMap:
Для этого все создаваемые маппером объекты нужно обернуть в проксирующие дектораторы. Которые декорируют метод объекта getId(), без фактического обращения к объекту. Иногда это выручает, т.к. не всем нужно кроме Id элемента что-то ещё.
Этот проксирующий декоратор позволит создать объект, в случае, если хранилище IdentityMap было инвалидировано.
Зависимые загрузки. Проблема 1+n запросов.
$posts = $user->posts() и затем foreach $posts->comments() фактически вызовет N запросов(для каждого поста по запросу), решается уведомлением зависимого маппера о вероятном использовании некоторых объектов. Например CommentMapper::notifyUsage($comment_id) или MapersManager::getMapper(‘comment’)->notifyUsage($comment_id);
Но для этого нужно отказаться от итератора над коллекцией возвращаемых значений для постов.
Связи. Самое сложное, 2 решения:
Скрипты(отчёты, регламентные процедуры, и.т.д.):
Скрипты в доменной модели, всегда веселуха. Напрямую обращаться к базе нельзя, всё через уровень доменной модели. Медленно.
Резюме:
Это только первый слой, без Data Abstration Layer. Выглядит уже сложно. Возникает ощущение программирования ради программирования.
Как возможная альтернатива: Анемичная модель и отказ от объектов пользу массивов. Интеграция приложения на уровне базы данных, когда всё приложение пронизано знанием о способе хранения и структуре возвращаемых данных.
Как показывает опыт анемичная модель доминирует в вебе. Суппорт анемичной модели так же более лёгкое занятие.
Для разработчиков : M101: MongoDB for Developers
и для DBA: M102: MongoDB for DBAs
Статья на хабре: http://habrahabr.ru/post/153429/
Вот что происходит в craigslist:
Как они заюзали MongoDB тут: http://www.10gen.com/presentations/mongosf2011/craigslist
ТЗ: организовать релевантный поиск.
ТУ: данные хранятся в MongoDB, бэкенд на PHP.
Читать полностью »
Допустим у нас есть объект — курсор из субд. Но мы хотим расширить его, для возвращения объектов. Добавить метод next_object(), который будет использовать метод getNext()
Проблема:
Мы не можем заставить модель возвращать объекты другого типа.
Решение 1: сделать итератор на этот курсор(который тоже является итератором). Сделать много магии для методов и свойств и получить новый итератор с нужным нам свойством.
Решение 2: Для PHP 5.4.0, использовать анонимные функции. О нём я и расскажу:
Внутри мапера, в методе findWhere($where) сделаем добавление анонимной функции в курсор, с передачей колбека и самого курсора
/** * @return MongoCursor */ public function findWhere($where) { $collection=$this->collection->find($where); $callback=$this; $collection->next_object=function() use ($collection, $callback) { $data=$collection->getNext(); $obj=$callback->create_object($data); return ($obj); }; return ($collection); } |
Теперь, по идее можно обращаться к $collection->next_object() и получать объект, созданный мапером. Но к сожалению это не работает, т.к. PHP попробует выполнить user_func_array и не найдёт метод. Для этого присваиваем свойство переменной, значение которого является анонимной функцией и выполняем, через $func():
public function findOneWhere($where) { $collection=$this->findWhere($where); $func=$collection->next_object; return ($func()); } |
Кривенько, но работает.
Забавная особенность метода count(), применительно к курсору результата запроса.
$items=$collection->find($where)->sort($sort)->limit($limit)->skip($offset*$limit); var_dump($items->count()); //1 var_dump($items->count(true)); //2 |
в первом случае получим count всех записей, без учёта limit и skip, но с учётом where
во втором случае получим count записей с учётом limit, skip, where.