Взаимодействие нескольких репозиториев. Как объединить?

Question

[fman2]

Здравствуйте.

У меня в системе есть примерно вот такая структура:

shop/
--entity/
------Product.php
------ProductType.php
------Category.php
--repository/
------ProductRepository.php
------CategoryRepository.php
------ProductTypeRepository.php
.... и еще....

interface CategoryRepositoryInterface
{
     public function findOne($id): CategoryInterface;
     public function findAll(): array;
     public function save(CategoryInterface $category);
     public function remove(CategoryInterface $category);
}

interface ProductRepository
{
   // .... все тоже самое, что и у CategoryRepositoryInterface
}

Product состоит из двух дополнительных частей (сильно упрощено, сущность с товаром довольно толстая):

interface Product
{
     public function addCategory(CategoryInterface $category);

     public function setProductType(ProductTypeInterface $productTypeInterface);
}

И тут возникает несколько проблем.
Первое, в ProductRepository нужно собрать из всех других репозиториев и вернуть через findOne() товар со всеми зависимостями (тип товара, категория, изображения, лицензии и прочее). Получается, что ProductRepository зависит от других репозиториев (Category, ProductType, Image, File....).

При удалении категории через $categoryRepository->remove() удаляются и товары (там бизнес логика на удаление завязана). Получается ад, репозиторий с категориями зависит от товара. А репозиторий с товарами зависит от репозитория с категориями и еще от нескольких других репозиториев. И тут у меня наступил dependency-hell.

В клиентском коде все должно быть просто:

$productRepository->findOne(100); // вжух и мы получили товар со всеми зависимостями и ИД 100.

Теперь главный вопрос - как собирать товар (или другую сущность) из разных кусков?

Сейчас я вызываю в методе findOne() репозитория соответствующие методы репозиториев других частей. Чувствую, что это неправильно, но как быть? Какие у вас практики, когда сущность собирается из разных кусков?

Как обрабатывать метод $productRepository->save($product), если разные куски товара сохраняются по-разному. Я сейчас прямо из метода save() дергаю отдельные репозитории в транзакции и сохраняю их. Правильно ли это?
Как быть с масштабированием, если в будущем появится еще что-то?

Comments

[Максим Федоров]

вам нужен сервис, который бы работал с репозиториями

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

просто еще один слой

Answer 1

[Александр Макаров]

Получается, что ProductRepository зависит от других репозиториев (Category, ProductType, Image, File....).

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

Теперь главный вопрос - как собирать товар (или другую сущность) из разных кусков?

Руками.

Как обрабатывать метод $productRepository->save($product), если разные куски товара сохраняются по-разному.

Индивидуально. Руками.

Как быть с масштабированием, если в будущем появится еще что-то?

Или взять ORM или, опять же, руками. Не бойтесь писать код и не бойтесь его дублирования в разумных пределах. Не всё то DRY что им кажется.

Comments

[fman2]

Спасибо за ответ, а если действительно сделать ещё один сервисный слой и в нем дергать методы соответствующих репозиториев, а репозитории сделать независимыми?

[Александр Макаров]

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

[nicandr]

Правильно, для этого кокрас можно использовать facade, чтобы можно было легко менять логику за ним возвращая результаты которые ожидает клиент. Еще Common Reuse Principle кокрас говорит что надо использовать компоненты вместе которые принадлежат одной задаче. Так если изменится один, не надо по всей системе искать что он сломал, а только в компоненте(или бизнес задаче) которому он принадлежит, ну и тесты конечно.

[Андрей К]

Согласен, как раз вчера тоже самое обсуждали на примере .Net, там есть ViewModel которая относится только ко View, а для REST ее использовать не правильно, но клиентская валидация в ней.

Вот и тоже пришли к консенсусу, что не все на самом деле является дублированием, что на него похоже.

Ну и ко второму выводу пришел я один, что для веб чаще больше подходит Active Record, но мой друг со мной не согласился ))).

А вот на работе у нас Yii2 с его чудесным AR.

[fman2]

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

interface ProductSaveService
{
    public function save(ProductInterface $product);
}

И уже этот сервис сохраняет товар по частям в разных репозиториях. Так же можно?

[Александр Макаров]

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

[nicandr]

Для этого и есть в солиде бувка О, open closed principle, нельзя модифицировать логику, а можно расштрять, если принципу следовать тогда ничего не поломается. Нужно сделать новую реализацию, пожалуйста, используйте тот же интерфеис и делайте новую логику.

Answer 2

[nicandr]

Максим Федоров правильно вам написал, вам нужен еще один слой который будет взаимодействовать с вашими репозиториями, в симфони как и в лбдом другом фреимворке вся логика должна быть в сервисе. Из вашего описания вы сделали facade паттерн чтобы в клиентском коде все бьло просто. Для этого подойдет сервис, который может который так же модет наследовать(implement) интерфейс.

interface CategoryRepositoryInterface
{
     public function findOne($id);
     public function findAll(): array;
     public function save(CategoryInterface $category);
     public function remove(CategoryInterface $category);
}
class CustomNameOfClass implements CategoryRepositoryInterface // ну тут имя лучше изменить
{
      public function findOne($id){};  // тут тоже лучше иметь return type
     public function findAll(){}: array;
     public function save(CategoryInterface $category){}; // тут тоже лучше иметь return type
     public function remove(CategoryInterface $category){}; // тут тоже лучше иметь return type
}

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

Answer 3

[dmitriy]

А почему бы работу со связями не возложить на ORM?

Answer 4

[Виктор Мамонов]

Не знаю, насколько это хорошо в архитектурном плане. Как вариант, можно, у сущности Product добавить методы-геттеры или методы-модификаторы, которые будут дергать нужные репозитории.

$product = $productRepository->findOne(100);
$product->getCategories(); // Здесь по принципу lazy load ищем в нужном репозитории
$product->removeCategories();

В результате, так по цепочке можно связываться с нужными хранилищами.

Comments

[fman2]

Я похожим способом сделал, entity не имеет методов remove*, она только либо получает данные, либо их возвращает. А вот заполнение происходит через callback функции и lazy-load.