Ну я как раз про это - считать ли например persistence частью бизне-логики / поведения объекта, или нет?

Ну я как раз про это - считать ли например persistence частью бизне-логики / поведения объекта, или нет?

давай так... почему тебе нужен слой персистентности?

Если считать - то по моему разумению active record как-то не особо анемично выглядит.

давай так... почему тебе нужен слой персистентности?

Ок, убедительно.

потому что того требует бизнес логика или потому что у тебя есть ограничения в духе "я не могу просто оставить объект висеть в памяти и мне надо куда-то его сохранить, но бизнесу плевать куда и почему"

Ок, убедительно.

persistance layer это часть инфраструктуры. То без чего проект работать не будет но это что-то что не влияет на бизнес логику от слова совсем. И в идеале бизнес логика вообще ничего не должна об этом знать.

но последнего добиться весьма и весьма сложно

Да, собственно оно после вопроса "как соотносится с бизнесом" все стало на свое места.

Потому я и написал "убедительно" - действительно, анемичные модели - это про отсутсвие бизнес-логики в них, а персистентность оно не про бизнес, оно про ограничения технологии.

Таким образом наличие какого-то кода для сохранения в active record на анемичность не то чтобы как-то влияло.

Спасибо!

а можешь сказать чем плохи анемичные модели?)

в моём разумении - примерно тем же, чем и глобальные данные

в моём разумении - примерно тем же, чем и глобальные данные

отсутствием контроля доступа?

ну ты можешь схитрить и навесить проверку инвариантов на стэйт, и дергать проверки всякий раз как мы меняем стэйт

ну то есть не все так плохо как тупо с глобальным стэйтом

отсутствием контроля доступа?

раскрытием внутреннией реализации в первую очередь - и отсутстивие контроля доступа я рассматриваю как последствие оного

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

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

опять же, у тебя есть одно место где лежит стэйт, и ты можешь спокойно трекать остается ли стэйт валидным.

а вот последнее - соглашусь

ну мол что мы ничерта не знаем о поведении

опять же, у тебя есть одно место где лежит стэйт, и ты можешь спокойно трекать остается ли стэйт валидным.

это мне кажется менее существенным - именно по причине возможности валидации (о чем ты как раз и написал)

ну мол что мы ничерта не знаем о поведении

в моей практике это чуть не основная пробема вообще в разработке - "хз как оно работает". со всеми вытекающими последствиями - сложно maintain, сложно расширять, сложно модифицировать, сложно knowledge transfer и т.д.

ну тип того да)

с другой стороны если ты будешь иметь отдельную модель данных и она будет использоваться в контексте конкретного доменного объекта - весь профит сохраняется

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

ну мол даже AR - ты можешь делать полноценую модель с ним

а можешь не делать

теперь мне идея более ясна

спасибо

просто AR подразумевает что логики мало, а если ее много - надо просто уже смотреть в сторону Row Data GAteway

а какие еще есть варианты кроме active record, data mapper, row data gateway ?

а какие еще есть варианты кроме active record, data mapper, row data gateway ?

table gateway, dao

так про dao Знал

в целом оно покрывает все потребности

но он очень похож на data mapper :D

но он очень похож на data mapper :D

нуууу.... как сделаешь так и будет)

ты можешь внутри dao юзать AR илли data mapper

верней у нас давно было забавно, юзали hibernate а потом над hibernate был dao

а над dao слой сервисов)

зачем вам хибернейт тогда)

ага было забавно, там я был девелопером прост)

вот я сейчас сижу и думаю... вот есть у меня ORM... она мне сущности выплевывает... для операций записи вообще чудо

а вот чтение...

там была очень "прикольная" архитектура (для крупного заказчика)

да мне orm Не нравится на чтение

мне надо тупо выплюнуть массивчик джесонкой... нафиг мне этот жирнющий слой для этого

мне орм не нравится

сижу и размышляю над плюсами и минусами различных подходов к этому добру

я думал над вариантом что почему бы не сделать QueryInterface

и объекты которые разные запросы создают и placeholder проставляют

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

но это муторно

и некий QueryManager ( как EntityManager)

и некий QueryManager ( как EntityManager)

ну у меня он Finder называется

``` interface Finder { public function find(Query $query); }

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

опа опа

и как такая архитектура ? я просто о таком думал но на бою не проверял

и как такая архитектура ? я просто о таком думал но на бою не проверял

ну у меня там сущности пока выплевываются.... потому разницы особо нет) просто каждой выборке свой QUERY

нужен поиск по каталогу - ProductSearchQuery

а маппинг query на сущность?

а маппинг query на сущность?

не, там внутри через доктриновский query buider пока-что

получается есть сущность

которая внутри создает query и получает результаты

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

и это все скрыто (инкапсулированно)

ERROR: S client not available

select new ProductItemView( p.id, p.details // embeddable штука m.profile // embeddable штука )

которая внутри создает query и получает результаты

ну у меня ровно то же самое

public function find(Query $query) { $qb = $this->em->createQueryBuilder(); return $query->prepare($qb)->getQuery()->getResult(); }

я просто к этой идеи пришел но не видел чтобы где то это применялось

у тебя что-то похожее?

ога да

я к этому пришел но пока проект не таким образом

я просто думал что это было бы удобно

я такой подход в сыром виде уже пол года применяю на своих проектах

в целом народу нравится

но мне не нравится)

но только работу над бд сделать не через доктрину а через pdo

ну то есть сама идея как по мне логична, но реализация отстой

но только работу над бд сделать не через доктрину а через pdo

это добавляет приличный оверхэд по времени разработки

я думал сделать либу чисто для проверки

а потом может обкатать на практике

https://github.com/K-Phoen/rulerz

может натолкнет тебя на мысли какие

как по мне крутая штука НО оно хочет уметь слишком много)

ну я не очень сторонник Query билдеров

которые в oop стиле

чуваки не хотят понимать sql и придумывают oop обертки

посмотрю либу может свое что по напишу)

чуваки не хотят понимать sql и придумывают oop обертки

проблема в "не хотят понимать SQL" а в желании делать композицию

ну мол...

$query = someCriteria() + someOtherCriteria() + someOtherStuff();

c SQL ты такое не провернешь

да и некоторые вещи удобнее выражать

SQL то для query builder-ов всеравно надо знать

ну да возможно

это холиварно надо делать prof of concept и смотреть)

возможно какой проект на таком делать