Я собираюсь перейти на Чистую архитектуру и поднять свой уровень Android с MVC на MVP , представляя DI с Dagger 2, Reactivity с RxJava 2 и, конечно, Java 8.
В чистой архитектуре MVP существует слой между объектами (в хранилищах данных) и презентаторами, которые должны получить к ним доступ. Этот слой является «вариантом использования» . Вариант использования - это в идеале интерфейс, который реализует ОДНУ операцию на ОДНОЙ сущности.
Я также знаю, что «Чистая архитектура» « кричит », в смысле ее проекты действительно хорошо читаются, так как в них большое количество классов.
Теперь, в моем проекте, у меня есть что-то вроде 6 разных сущностей , и, конечно, у каждого хранилища сущностей есть по крайней мере 4 метода (обычно get, add, delete, update) для доступа к ним .. так, 6 * 4 = 24 .
Если то, что я до сих пор понимал в Чистой Архитектуре, у меня будет 24 UseCase.
Это много классов по сравнению с 6 контроллерами в MVC.
Я действительно должен сделать 24 случая использования?
Я буду очень признателен за разъяснение кем-то, кто уже использовал его с успехом.
Спасибо джек
Ответы:
Только если все, что вы пишете, является CRUD .
Обратитесь к диаграмме ниже:
Вы утверждаете, что у вас будет шесть разных сущностей и 4 метода (Create, Read, Update и Delete) для каждой сущности. Но это верно только для желтого круга в середине диаграммы (слой сущностей). Нет смысла создавать 24 метода в слое Use Cases, которые просто проходят через вызовы CRUD к слою Entities.
Вариант использования не «Добавить запись клиента». Вариант использования более похож на «Продать товар покупателю» (который включает сущности « Клиент», «Продукт» и «Инвентаризация») или «Распечатать счет» (который включает в себя те же сущности, в дополнение к заголовку счета и отдельным позициям счета- фактуры). ).
При создании вариантов использования вы должны думать о бизнес-транзакциях, а не о методах CRUD.
Дальнейшее чтение
Агрегат - кластер объектов домена, которые можно рассматривать как единое целое
источник
Вы правы, если каждая CRUD-операция переводится в один UseCase. Но UseCase также может состоять из нескольких CRUD-операций.
UseCase - это отдельная модель, собирающая информацию из разных источников данных и подготавливающая связь с приемниками данных. Может быть задействовано несколько CRUD-операций.
Так что подумайте о UseCase, где создается счет для клиента И также создается сам клиент, потому что он / она не существует в системе. У вас есть один UseCase, который приводит как минимум к двум Create-Operations в одной транзакции.
источник
Ваше определение Use Case неверно, Use Case - это класс, реализующий бизнес-правило, оно не должно быть операцией CRUD, это может быть сложная многошаговая операция
источник