Я не согласен, и попробую обьяснить на примере. Существует паттерн MVP.

Question

Я не согласен, и попробую обьяснить на примере. Существует паттерн MVP.

Идея одна.
Сущесутет фреймворк, который реализует этот паттерн.
Мокси.
Мосби.
Можно без фреймворка.

Паттерн один. Реализации уже 3.

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

Как следствие: бойлерплейт порождается реализацией того или иного паттерна, а не его идеей.

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

- Ну тут как посмотреть, в акторах MVICore и в редьюсерах TEA может спокойно размещаться вся бизнес логика фичи.
- она то может, но место ли ей там?

Это вопросы не на уровне реализации, а на уровне проектирования (ака идеи реализации)

- Да, можно использовать MVI чисто как презентационный паттерн и тогда выходит тот же MVP только сбоку
- То-что MVP , но только сбоку, так это же и замечательно.

замечательно потому что они оба представляют собой идею коммуникации между слоями отображения и модели.
Они решают одну цель
Они на уровне идеи делают это разными способами коммуникации
На уровне реализации они делают это еще более разными способами

Обьясню это таким образом.

Если бы MVI был паттерном для Модели, то при таком подходе конкретную реализации модели отличалась бы от той, что у нас есть в MVP, или, они были бы не совместимы.

Но при правильной реализацией MVP мы можем иметь абсолютно такую же реализацию модели как и в MVI, но на уровне соединения Модели и Отображения:
- МВП бы получал изменения с модели по подписке и отправлял их на Вью через команды, а события в Презентер отправлялись бы тоже командами
- MVI бы получал изменения с модели по подписке и редюсил бы их в ViewState, который бы отправлялся во вью через метод render, а получение данных происходило бы по подписке на вью.

#it #programming #russian #software

0

13.06.2019

1 ответов

19 просмотров

Mikhail L · Accepted Answer

> Если отталкиваться от того, что паттерн стимулирует написание бойлерплейта, то это означает, что все три реализации одинаково много предоставляют его. Что не верно, потому что последний явно больше требует написания кода, который можно было орагинзовать. если паттерн требует написания бойлерплейта, то любая его реализация не может предоставить меньше бойлерплейта. Больше - сколько угодно. MVP с долгоживущим презентером требуют как минимум задекларировать интерфейс view и иметь способ для сохранения состояния между пересозданиями вью > как итог: нет реализации Модели по MVI, и нет реализации модели по MVP. сорян, но это доказательство через утверждение какое-то. "я использую MVI только как презентационный паттерн и поэтому бизнес логику в него помещать нельзя"

214 похожих чатов

Я не согласен, и попробую обьяснить на примере. Существует паттерн MVP.

1 ответов

Похожие вопросы