Комментарии 14
Вы строите свой query builder с equals, and, not поверх уже сделанного query builder. Зачем?
В статье есть ссылки на другие аспекты использования спецификаций, я же сосредоточился на переиспользовании бизнес-правил как для формирования выборки, так и для проверки отдельного объекта. Вот буквально пример из повседневной практики в дополнение к тем, что уже приведены в статье:
При обновлении email пользователя подтвердить его изменение можно в течение 5 минут после отправки письма с кодом. При этом в одном месте приложения проверяется, что запрос еще актуален, а в другом формируется dql на очистку всех устаревших запросов. С помощью паттерна спецификация можно создать один класс IsActual и переиспользовать его как для проверки единичного запроса, так и для очистки всех устаревших.
С помощью query builder вы напрямую это не сделаете. Разве что сможете проверить, что ваша единичная сущность входит в состав общей выборки. Но это как-то жестко что ли…
Композиция, переиспользование, возможность применять к отдельным объектам.
Кажется все это query builder делает, я беру LINQ как пример. Композиция присутствует, переиспользование запросто — вытаскиваем то, что хотим реюзать в метод. Спецификации, должно быть, хороший способ реюзать запросы. Но заигрывания с композицией могут привести к необходимости обернуть все апи query object. А это уже код ради кода.
В doctrine ORM query builder, по сути, является надстройкой над строками dql. Безусловно, куски $queryBuilder->andWhere('a = :b); можно выносить в отдельные методы, но насколько удобно будет их переиспользовать и как их композировать, нме не сильно понятно. Я применение такого подхода на практике вижу довольно редко.
Вообще о паттерне «Спецификация» я впервые услышал применительно к C#. Там она построена на expression. Следовательно для него этот шаблон тоже актуален.
Да и по поводу лишнего кода… Конечно, необходимо наладить свою инфраструктуру. Существующие библиотеки как-то пытаются это сделать. Но даже построение ее с нуля не выглядит сложной задачей. Дополнительные операции можно добавлять по мере необходимости и кода в них немного. Зато сами бизнес-правила довольно локаничны, выглядят понятно и предсказуемо.
В C# спецификация в виде отдельного объекта не особо нужна. Там можно написать что-то вроде db.Messages.Recipient(User).OrderBy(x => x.CreatedAt).Take(100); в результате получается Expression, к
при желании эту строчку можно поместить в метод и реюзать где угодно. Этот Expression и есть встроенная в язык/рантайм спецификация. В любом другом языке, если есть достаточно мощный query builder, можно делать то же самое.
создать один класс IsActual и переиспользовать его как для проверки единичного запроса, так и для очистки всех устаревших
В Yii для этого можно сделать Query, специфичный для модели, и писать там методы с названиями из бизнес-логики, которые настраивают фильтр нужным образом. Существующий в приложении объект им не проверить, но теоретически можно написать метод, который будет брать фильтры из запроса и делать аналогичные проверки в приложении.
Ну, и раз вы пишете «теоретически», то в повседневной практике так не делаете? Как вы тогда решаете эту проблему? Просто пишите логику 2 раза?
Нет, создается класс UserQuery extends ActiveQuery, там пишутся методы типа isActive() { return $this->andWhere(['=', 'is_active', 1]); }, в коде делается так $users = User::find()->isActive().... Вот этот массив, которым задается условие, кладется в объект запроса, и теоретически их можно обрабатывать, чтобы проверить соответствие сущности.
Я так не делал, обычно да, пишут проверки 2 раза. Но большинство из них простые, особых проблем это не создает, поэтому решение никто особо и не ищет.
Тогда ваш массив с условием и будет, по сути, спецификацией. Их кто-то и в строковом виде создает. Вопрос лишь в том, какие возможности предоставляет выразительность такого формата.
sentAt для простоты хранится в timestamp
class ChangeEmailRequest
{
public int sentAt;
}
final class IsActual extends CompositeSpecification
{
public function __construct(private int $lifeTime)
{
}
public function getSpecification(): Specification
{
return new GreaterThan('sentAt', time() - $this->lifeTime);
}
}
final class ChangeEmailController
{
public function confirm(ChangeEmailRequest $changeEmailRequest, IsActual $isActual): Response
{
if (!$isActual->isSatisfiedBy($changeEmailRequest)) {
throw new \Exception();
}
//...
}
}
final class ChangeEmailRequestRepository
{
public function __construct(private IsActual $isActual)
{
}
public function clearOldRequests(): void
{
$queryBuilder = $this->createQueryBuilder('r')
->delete();
$isNotActual = new Not($this->isActual);
$isNotActual->filter($queryBuilder);
$queryBuilder->getQuery()
->execute();
}
}
Спецификации редко используются потому, что, имхо, подобные реализации, с одной стороны, гвоздями прибиты к той или иной инфраструктуре а, с другой, в PHP нет стандарта интерфейсов хотя бы де-факто для коллекций и ORM, чтобы это можно было игнорировать. Ну и средства обобщенного программирования не самые развитые.
На первый взгляд кажется, что логику применения спецификации можно расположить и во внешних сервисах, что позволит применять их для разных платформ. rulerz, кв конечном счете, так и поступил. Разве что для этого им был создан особый DSL. Но, думаю, можно обойтись и без него.
Возможно, сам подход контринтуитивен. Плюс не для всех проектов описанные в статье проблемы так уж актуальны.
Еще, вероятно, на более сложных примерах возникнет проблема натягивания спецификаций и на объект и на БД. Все-таки у ORM есть границы применимости.
Ну вот в поддержке платформ я основную проблему и вижу.
Ну и общая сложность полной реализации паттерна: хорошо бы иметь единообразный способ не только фильтровать источники данных и проверять подходит объект или нет, но и создавать новые объекты на основе спецификаций, равно как при проверке выводить чем именно не подходит объект под спецификации.
Сам подход вроде интуитивен, но многословен слишком
Ещё, вероятно, нужна комбинация фильтров для разных источников — той же доктрины и эластика со связью по первичному ключу. Хардкодом элементарно делается...
Все примеры, которые удавалось видеть — плохие и так или иначе приходилось возвращаться к простому Query Builder, а то и вообще чаще к SQL
Сложные выборки строить через спецификацию = закраивать высокую связанность на уровне бизнес-сущностей
Пара слов о спецификациях