Как отделить бизнес-логику от Rx - PullRequest
0 голосов
/ 25 апреля 2018

Я хочу применить Чистая архитектура дяди Боба . Это ограничивает ядро ​​приложения - сущности и бизнес-логику - независимостью от внешнего мира, особенно от выбора конкретной среды.

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

Предположим, что я пишу кеш аутентификации на стороне клиента, и он отвечает за предоставление сертификата входа в систему, если таковой имеется в кеше, и при необходимости извлекает его с сервера. Тогда мне нужен интерфейс IServer (только интерфейс, конкретная реализация будет проблемой "внешнего уровня"):

interface IServer {
    getCertificate(phone: string, password: string): Observable
}

Могу ли я каким-то образом изменить эту зависимость от Observable?

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

interface IServer {
    getCertificate(phone: string, password: string, callback: () => Void)
}

Это единственный способ?

Или

Должен ли я сначала отделить Rx от моей логики?


Вторая мысль: существует ли какой-либо абстрактный интерфейс интерфейса / протокола для включения в мой проект? (p.s. Я использую машинопись)

Тогда возникает проблема: моя бизнес-логика зависит от абстрактного определения интерфейса ReactiveX, и я могу пойти с этим. Я могу рассматривать это как фундаментальный выбор, который я должен сделать на ранней стадии, например, выбор языка программирования.

1 Ответ

0 голосов
/ 29 апреля 2018

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

Это говорит о том, что Observables похожи на обещания, используемые для абстрагирования потоков. Если наблюдаемые интерфейсы и классы взяты из стандартной библиотеки языка, как в .Net, их использование в вашей бизнес-логике, вероятно, не такая уж большая проблема. С другой стороны, если эти интерфейсы и классы поступают из сторонних библиотек, вы должны быть осторожны и можете рассмотреть возможность их абстрагирования, например. использование адаптера и заводских шаблонов для поддержания чистоты бизнес-логики.

Обновление: Более подробное обсуждение "как интегрировать фреймворки в чистую архитектуру", пожалуйста, смотрите в моем блоге http://www.plainionist.net/Implementing-Clean-Architecture-Frameworks/

...