Вопрос:
Согласно чистой архитектуре, дизайн Interactor является частью, которая содержит всю бизнес-логику. Термин Interactor довольно запутан для меня. Мне кажется, что Interactor взаимодействует между двумя разными уровнями, такими как данные и докладчик.
Это правильный термин для использования? Может кто-нибудь, пожалуйста, проясните цель Interactor? Какой шаблон это следует? Если Interactor – это не то, что мне кажется, то каков шаблон проектирования для взаимодействия между слоями?
Лучший ответ:
Interactor – это шаблон дизайна, который не имеет ничего общего с концепцией бизнес-логики. Не вдаваясь в более глубокий уровень детализации, шаблон Interactor является расширением шаблона Command; Каждый объект “бизнес-логики” рассматривается как “черный ящик”, простая инструкция для клиента, развязающая объект, который вызывает операцию, из той, которая знает, как ее выполнять. (см. библиографию для расширенного объяснения).
В среде Android есть простое “правило”, которое требует, чтобы программист выполнял долговременную задачу в фоновом потоке, поэтому шаблоны взаимодействия расширяют “командный шаблон”, добавляя слой потоковой передачи. Все эти сложные вещи реализованы для создания “чистой архитектуры”, которая влечет за собой масштабируемый, ремонтируемый и (возможно) понятный код.
О вопросе.. ¿Каков шаблон проектирования для взаимодействия на уровне слоев? Это может иметь более одного правильного ответа, зависит от ситуации. В качестве точки входа можно использовать простой интерфейс, поэтому вы можете использовать шаблон адаптера или, возможно, шаблон Facade, или если вы хотите сделать что-то более продвинутое, вы можете реализовать систему eventbus.
Источник:
Дизайн шаблонов объясняется просто – auth Александр Швец. стр. 14 (адаптер), стр. 32 (команда), стр. 47 (фасад)
Ответ №1
Interactors предоставляет реализации для различных вариантов использования. В идеале в каждом случае использования должен быть один интерактор, но он может отличаться в зависимости от масштаба вашего приложения.
Теперь, почему это не имеет смысла для каждого приложения? Представьте, что у вас есть два приложения. В первом приложении вам просто нужно прочитать пользователя. В другом приложении вы просто обновляете того же пользователя. У вас будет два разных интерактора, таких как GetUserInteractor и UpdateUserInteractor. Если подумать, UpdateUserInteractor не будет иметь никакого смысла для первого приложения (и наоборот), верно? Но логика вашего бизнеса/домена для обоих приложений может быть одинаковой, если реализации обеих служб (чтение и обновление) включены, например, в соответствующий объект бизнеса/домена (или как отдельные объекты варианта использования). Эти объекты, очевидно, инкапсулируют не зависящие от приложения бизнес-правила, поскольку их можно подключить к двум или более различным приложениям.
Связь между приложением и пользователями часто зависит от конкретного приложения. Как уже упоминалось, ваши интеракторы могут выполнять команды для действий пользователя. Или вы можете пойти другим путем. Но шаблон команды действительно удобен и, возможно, делает весь код более согласованным, единообразным и простым для понимания.
Наконец, что не менее важно, другим важным аспектом интеракторов являются “граничные интерфейсы”, которые представляют собой классы, которые полиморфно развертываются как для доставки ввода, так и для вывода.
(PS: Например, в Android, с новыми компонентами архитектуры, Fragment/Activity можно рассматривать как реализацию входной границы, когда вы доставляете входные события в свою бизнес-логику (или модель домена) – это контроллер. LiveData – это больше похоже на реализацию выходной границы, поскольку она использует шаблон наблюдателя под капотом и доставляет данные обратно в пользовательский интерфейс через интерактор. В этом случае, я думаю, это делает ViewModel сильным кандидатом на роль интерактора, поскольку он получает входные события ( и команды, соответствующие этим событиям), а также содержит экземпляр LiveData, который нужно наблюдать. Все ли эти развязки хороши или полиморфно развернуты? Ну, это в основном связано с вашим дизайном. А с сопрограммами теперь кажется, что нет необходимости в обратных вызовах/слушатели – это другое измерение в этой картине.)
Это мой дубль. Надеюсь понятно.
Ответ №2
Из того, что я читаю, это эквивалент Presenter в архитектуре View Viewer (MVP).
Это бизнес-логика, а не хранение или отображение данных. Он создает отдельный слой независимо от того, как и где хранятся или отображаются данные. Он заботится только о входах и выходах в любом формате. Его можно использовать в сочетании шаблонов Observer, Adapter и Façade, чтобы быть интерфейсом для обратных вызовов, общей точкой расширения кода и развязанной точкой входа для любого нелицензионного или информационного хранилища, соответственно.
Я предполагаю, что он называется Interactor, потому что View взаимодействует с ним для вычисления значений и обновления любых отображаемых элементов пользовательского интерфейса, и он взаимодействует с объектами Model для извлечения данных. Он также может взаимодействовать с базой данных для операций CRUD, но я думаю, что они в основном рассматриваются в шаблоне репозитория, поскольку это не бизнес-логика.
Ответ №3
Это шаблон MVP. Да, как вы сказали, это медиатор между презентатором и данными (как форма отдыха или общего предпочтения или Sqlite).
