> Сейчас есть базовый сервис, от которого все наследуется тут уже чувствуется проигрыш

> Сейчас есть базовый сервис, от которого все наследуется тут уже чувствуется проигрыш

да верно

это старый код 11 года

я это и хочу убрать

> И в этом сервисе есть метод massDelete который удаляет сущности с указанными id и логирует их ну то есть тебе надо просто каскадный софт делит, так?

> И в этом сервисе есть метод massDelete который удаляет сущности с указанными id и логирует их ну то есть тебе надо просто каскадный софт делит, так?

да

это инфраструктурная логика

еще логирование и проверка прав

проверка прав на уровне точки входа в бизнес транзакцию

просто выносишь ее повыше

это инфраструктурная логика

почему? я думал это бизнесс правило.

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

почему? я думал это бизнесс правило.

ну у тебя это конкретно проблема инфраструктуры. Либо у тебя есть сущность которая просит весь свой грфа поменять стэйт

типа

public function remove() { $this->removed = true; foreach ($this->someRelatedItems as $item) { $item->remove(); } }

а тот ходит по своим детям

и тд.

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

а логирование можно делать через доменные ивенты

в любом случае я плохо понимаю причем тут AOP

Как расшифровывается АОП

аспектно оринтированное программирование

public function remove() { $this->removed = true; foreach ($this->someRelatedItems as $item) { $item->remove(); } }

А чем плох такой вариант?

А чем плох такой вариант?

норм вариант

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

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

Просто и я не вижу :-) мне кажется простой и нормальный вариант, и можно не выдумывать всякие АОПы )

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

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

По хорошему тесты нужны всегда.

кроме случаев, когда ты решил сделать откровенно плохо.

от у меня есть доки по yii. я использую компоненты оттуда. их работа, как я понимаю, уже протестирована и на этом заострять внимание не надо?

нуу ты должен тестировать не компоненты, а поведение

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

чего-то как-то вообще мне сложно с этим

что угодно от unity тестов или интеграционные, до property based testing, ты смотришь в угол угла, почитай литературу сам поймешь, что тебе необходимо. Growing object oriented software guided by tests. Practical php testing Кент Бек XP

что угодно от unity тестов или интеграционные, до property based testing, ты смотришь в угол угла, почитай литературу сам поймешь, что тебе необходимо. Growing object oriented software guided by tests. Practical php testing Кент Бек XP

опа! спасибо тебе, добрый человек. это то что нужно

а то я еще и параноик) и мне самому себя надо страховать) вот тесты спецом для меня придумали, я точно знаю

> И в этом сервисе есть метод massDelete который удаляет сущности с указанными id и логирует их ну то есть тебе надо просто каскадный софт делит, так?

А можно это как то сделать стандартгыми средствами доктрины?

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

юнит тесты плохо совместимы с yii

по литературе добавлю еще - Working efficently with legacy code

А можно это как то сделать стандартгыми средствами доктрины?

что "это"? методы у сущностей сделать?

ну тут доктрина не причем - это простая работа с коллекциями и т.д.

Ну у доктрины есть каскадное удаление

есть каскадное удаление, но ему не это надо

точнее не совсем это

Я думаю у Артура ваще проблема с управлением корнями агрегатов

Самая главная - их нет

Мы еще раз обговорили и пришли к тому что надо делать каскадный soft delete

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

только soft

https://www.google.ru/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0ahUKEwj359vVpZPVAhXJE5oKHSKfAicQFggiMAA&url=https%3A%2F%2Fgithub.com%2FAtlantic18%2FDoctrineExtensions%2Fissues%2F505&usg=AFQjCNF239j0ehd_W8QLQzBGjjVye0hTqQ

я бы не придумывал магии и просто явно дергал бы hide() у сущностей

это проще, быстрее, явно, и времени на имплементацию у тебя уйдет меньше чем любая волшебная шляпа

а еще это можно тестить юнит тестами

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

То есть сейчас два варианта или искать доктриновскую нативную реализацию(которой нет похоже) или определить интрефейс с методом getChildren() и вызывать его при удаалении сущности с этим интерфейсом, ну и соответсвенно для всего что вернет gettChildren

а еще это можно тестить юнит тестами

мне пока не дали на них добро

что за getChildren?

мне пока не дали на них добро

а на них надо спрашивать разрешения?

ошибка новичка

что за getChildren?

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

То есть сейчас два варианта или искать доктриновскую нативную реализацию(которой нет похоже) или определить интрефейс с методом getChildren() и вызывать его при удаалении сущности с этим интерфейсом, ну и соответсвенно для всего что вернет gettChildren

я имею ввиду прямо в сущности сделать метод hide который выставляет стэйт и сам проходится по связям. В этом случае никаких getChildren не надо

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

нарушение принципа "информационный эксперт", нарушение закона деметры

почему ты не хочешь просто в сущности это делать?

а на них надо спрашивать разрешения?

да я на испыталке, и я свой план рефаторинга показывал на утверждение, тесты пока скзаали не делать

unit имею ввиду

ERROR: S client not available

почему ты не хочешь просто в сущности это делать?

так это и будет в сущности

так это и будет в сущности

ну так и зачем тебе там getChildren если у тебя ты и так знаешь какие релейшены и доступ к стэйту самой сущности у нее же есть

public function hide() { $this->hiddern = true; foreach ($this->someRelatedEntities as $entity) { $entity->hide(); // внутри тоже самое } }

никаких новых интерфейсов, никаких лишних геттеров

someRelatedEntities

так из получить надо же сначала

они необязаательно одного типа

....

в сущности

у тебя в ОДНОЙ сущности есть поле КОНКРЕТНОГо типа

я тебе привел метод "сущности"

какой-то, которая является вершиной графа сущностей в контексте твоей операции

она сама разберется кого еще попросить спрятаться

код верхнего уровня просто вызывает $entity->hide()

и не лезет в ее нутро

ООП и все такое

могу на gist накидать

и что мне в методе hide собирать всех детей?

давай я лучше накидаю как я вижу

и что мне в методе hide собирать всех детей?

зачем собирать, просто обходишь как я написал

сущность ДОЛЖНА знать о своих детях, и она прекрасно знает кого надо скрывать а кого нет

https://gist.github.com/fesor/67ed7ca31d2b51aa7f9e17a11a23e81c

а чем плох мой вариант

https://gist.github.com/arturpanteleev/240e8bbea8c7adcc80c2400e4e3b653b

мы здесь сможем вообще мтеод удаления в трейт вынести

мы здесь сможем вообще мтеод удаления в трейт вынести

а потом добавлять туда if-ы по мере разрастания логики

вынос логики в трейты это плохо

венгерская нотация тоже плохо

чувствуется запах c# 5-ти летней давности

по сути то точ ты сделал - это добавил ненужный геттер

$this->firstTypeSubEntity + $this->secondTypeSubEntity - так в php лучше не делать

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