Разбор ООП с Delphinum

Допустим у меня есть готовое решение без UoW.
Вот при вызове store там происходит следующее:

1. Открывается транзакция и управление потоком сохранения передаётся в рекурсивную функцию.
2. Функция принимает сущность, получает её связи и делит их на два типа: "мастер" т.е сущности от которых зависима наша сущность и "слэйв" т.е сущности которые зависят от нашей сущности.
3. Функция рекурсивно обходит все связи и отправляет их в БД. Сначала вверх по иерархии, а потом вниз для каждой делая все операции начиная с шага 2. Таким образом у нас отпадает нужда в топологической сортировке.
4. Выполняется транзакция. Если что-то пошло не так при вставке каких то данных, то выполняется rollback всего и выбрасывается исключение.

Примерно то же происходит при вызове метода remove.

Теперь я хочу понять, зачем здесь может быть нужен UoW?
Есть ли какие-то однозначные полезности, ради которых стоит вот эти моменты переписать на UoW.

# L!MP (14.02.2017 / 23:49)
Теперь я хочу понять, зачем здесь может быть нужен UoW?
Есть ли какие-то однозначные полезности, ради которых стоит вот эти моменты переписать на UoW.

Конечно может я не так понял твою задачу, но выскажу мнение...
===
Ну если следовать логике, то по своей сути UnitOfWork это аналог транзакционной модели.
Иными словами, ты можешь выполнять серию каких-то взаимосвязанных действий с данными.
Эти действия верны только вместе и они должны быть полностью завершены, или же отменены.
Транзакция в UnitOfWork завершается (сохраняются данные) только после коменды ->commit()
В этом и суть.
Происходит некое "накопление" данных.
Если по завершении работы скрипта не поступило команды ->commit() то транзакция считается незавершенной и будет произведен откат.

В MySQL транзакции возможны только в InnoDB, там без комита данные вообще не попадают в основную таблицу а хранятся в ЛОГ файлах. Если комита не последовало, то данные потом очищаются (физически никакого роллбэка нет, просто данные не добавятся).
===
Применять, или нет UnitOfWork зависит от ситуации.
В большинстве случаев транзакции не нужны. Но в некоторых случаях (к примеру принимаешь большой объем данных и медленно, или особо ответственный случай) может понадобиться.

Хорошая статья тут: http://blog.byndyu.ru/2010/07/ ... .html

L!MP, в основе DDD лежит сильное разделение модели и данных. В идеальном виде, модель вообще не должна знать, что она записывается или восстанавливается из БД. Без использования UoW невозможно или довольно сложно (кишки наружу) организовывать взаимодействие элементов модели, так как модели придется самостоятельно сообщать инфраструктуре о том, что данные пора отправлять в базу.

Повторю, кратко вопрос не раскрыть. Если обходишься без UoW, то не стоит морочиться, ибо прикрутить ее, как правило, не составляет особого труда.

Utility Classes Are Killing Us

Jahak, 50 минут про декомпозицию? Мужик крут )

Delphinum, Нет, за 15 минут управился, а все остальное время, - это ответы на вопросы)

Добавлено: 04.04.2017 / 17:31
Jahak, ну вообще очень уж простые вещи рассказывает чувак, мне кажется на конференциях нужно о чем то более передовом говорить

Добавлено: 11.04.2017 / 18:23
Про MVC под другим углом

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

class A {
private $b;
public function b() {
$this->b = new B;
return $this->b;
}

public function c(){
//
}
}

class B {
public function test() {
//
return $this;
}
}

$obj = new A;

$obj->a()->b()->test()->c();

чтоб из Б вернуться в А и продолжить цепочку
у меня почти получилось через __call
сори писал с телефона

Зачем?

ramzes, сделать красивую цепочку