Yii Framework

Если я правильно понял, то что zelenin предложил , не является на самом деле QueryObject, думаю просто название не верное выбрал, какой-нибудь PostSpecification наверное бы меньше путаницы бы внес. Хотя я по прежнему думаю такой билдер выносить за переделы имплементации доменной модели, не очень удо...

Если я правильно понял первый, то все это "выбор постов с фильтром по свойствам", это один метод репозитория, который проверит что фильтр верный и может быть использован, подготовит запрос и выберет посты из БД.

Идея - в передаче в репозиторий QueryObject (на основе UL) и поиска на его основе. Идея может быть интересной (ну может не Query Builder) это должно называться. Возможно, такая абстракция была бы интересной и удобной. Выглядеть это может примерно вот так: $query = (new PostQuery)     ->nameEqual('Н...

Понимаешь, в данной теме мы уже не про теорию, а про практику, в которой в методе как минимум должна быть пагинация. Не зная бизнес условий, вряд ли можно говорить о точном решении, но если условие будет что в домене нужна пагинация для результата поиска, то будет что-то вроде public function getSe...

Остальные два (сейчас посмотрел) тоже не имеет ничего общего с DDD, а являются врапперами над SQL (Like, Equals и тд). Разбрасывание бизнес логикой, а это как раз и есть бизнес логика как выбирается та или иная группа сущностей $specification = new CollectionSpecification([         new PageCondition...

zelenin писал(а):я специально привел три варианта реализации, чтобы показать как можно более удобно реализовать обертку над спекой с UL.

Я обсуждаю только вариант с билдером, он никак не относится к UL имхо.

И еще, вот написал ты в N сервисах билдер типа этого class MyService {   public function handle()   {     $query = new QueryBuilder();     $query->page(2, 15)       ->equal(['status' => Post::STATUS_PUBLISHED])       ->sign(['date' , '>', '2015-01-01'])       ->like(['name' , 'отпуск']);     $posts ...

так я и не говорю куда-то выносить фильтрацию/группировку. Если у нас в домене есть Repository+QueryObject, то реализация репозитория должна понимать этот QueryObject, преобразуя в свой нативный язык (sql ли это будет либо http-запросы к апи). Использование QueryBuilder, имхо, уходит далеко за пред...

Да именно похожее решение я эксперементально интегрирую сейчас в два баундед контекста, один CRUD другой CQRS, посмотрим во что это превратится .

плюс через 2-3 года разработки репозитории могут раздуться до 50 методов, поддерживающих различные типа выборок. Спецификация поможет сохранить чистоту. Чем плохи репозитории с 50 методов? Все хранится в одном классе, чей смысл это как список сущностей? Очень даже хорошо получается все контролирова...

И того же мнения. Спецификации, как фильтры сущностей, удобны, избавляют от кучи foreach, в боготом логикой домене. А вот генерация SQL в спецификациях, может быть интересна только как какой-то повторяющий код. Так что Double Dispatch мне не нравится, и я экспериментирую с другим решением.

Обратите внимание что Спецификация это часть домена, это часть Ubiquitous Language. Так что варианты типа Query Buidler не очень подходят ->page(2, 15) ->equal(['status' => Post::STATUS_PUBLISHED]) ->sign(['date' , '>', '2015-01-01']) ->like(['name' , 'отпуск']);   не очень хороший пример имхо. Когд...

zelenin писал(а):все верно, но вероятно, что на самом деле здесь не бизнес требования, а требования традиционных паттернов создания crud.

RESTful приложения тоже перенаправляют на созданную сущность а не на коллекцию.

Даже если мы сгенерим id и добавим его в команду, которую кинем в шину, а потом сделаем редирект на view/$id, то не факт, что найдем там страницу, а не 404, т.к. реализация шины возможно/вероятно асинхронна, и запись еще не создана, или не синхронизирована из write-хранилища в read-хранилища. Ну ес...

class ThreadRepository {   public function findThread($id)   {       return $this->build($this->query("SELECT * FROM threads WHERE id = :id", ['id' => $id]));   }      private function build($threadData)   {     return new Thread($threadData['title'], $threadData['body'], $threadData['aut...

Нарушает типизацию и семантику. И сами методы с или ... или ... только усложняются кучами if-ов. Сделайте два отдельных метода: save(Item $item) и saveAll(array $items). Могу посоветовать использовать Variadic functions в этому случае, очень smart получается, даже мощь type-hinting получаем public ...

ElisDN писал(а):Кстати да, клиентская валидация в формах может дублировать, но никак не заменяет валидацию внутри ядра. Клиентскую можно и не производить, если не нужно сразу поля по Ajax подсвечивать.

Поосторожнее с дублями правил, их несогласованность может привести клиента в ступор

Вынос ограничений сущности из сущности нарушение инкапсуляции. Если вы думаете, просто введя конвенцию в команде, что устанавливать надо в сущность только валидные данные проверенные до этого, и получите не убиваемый код, то вы сильно ошибаетесь. А еще больше ошибается ваш работодатель. После вас пр...

В norton commander не было черного. Черный на синим фоне - это вырвиглаз!

girmate писал(а):И что там за странные значки типа не тождественно равно, квадраты и так далее.

Изврат на тему ===, !==, []