Как стать автором
Обновить

Как мы выбрали архитектуру слоя представления на новом проекте и не прогадали

Время на прочтение 7 мин
Количество просмотров 13K
Всего голосов 15: ↑14 и ↓1 +13
Комментарии 9

Комментарии 9

Будут ли ссылочки на что нибудь? Чтобы посмотреть...

Скоро будет вторая часть, расскажем подробнее про то как у нас все устроено. Возможно в ближайшее время получится заопенсорсить нашу реализацию.
Если интересно что-то еще почитать про Elm, могу порекомендовать очень хорошую серию статей, правда на англоязычном Medium.

Спасибо

Классно) Elm выглядит интересным) буду ждать ваши дальнейшие посты) Особенно хочется посмотреть код, я учусь и не понимаю как с нуля организовать реализацию этого паттерна! Надеюсь у вас получиться сделать проект в свободном доступе!
Мы опубликовали следующую часть и в месте с ней открыли нашу реализацию Elmslie. Будем рады, если вы попробуете нашу библиотеку!
Очень интересно, но грамматические ошибки же! Глагол заканчивается на -ться, если это инфинитив, то есть отвечает на вопрос «что делать?»
Спасибо, исправил одну ошибку

А чем MVC и ему подобные не unidirectional? Данные идут из модели во вью, из вью (если мы говорим про современные интерфейсы) в контроллер передаются действия пользователя, который в свою очередь вызывает методы модели, которые обновляют данные и они идут во вью. Круг замкнулся.


Эти громкие новые названия ничего нового практического не приносят.


Вы же себя искусственно ограничили двумя вещами, как по мне:


  1. Завязка на экраны (я сужу по схеме с названием screen logic) самой логики.
  2. Созданием кучи ненужных классов. Это как в VIPER — много всего, а по факту половина не нужна.

И если судить по диаграмме с data store/actor и прочим — вы себя жестко завязали на хранилище, не использовав инверсию, но тут лишь мое предположение, возможно просто использовали упрощение при визуализации, хотя на мой взгляд это критичный момент для отображения если он имеется.

Спасибо за конструктивный комментарий.
1. В MVC действительно данные передаются только в одном направлении. Однако оно не регурирует то, как будет выглядеть Controller, а в нем может быть очень запутанный поток данных. MVI и подбные архитектуры имеют более подробное описание слоя представления, которое позволяет гарантировать, что даже в рамках него однонаправленность потока данных сохранится.
2. Завязка довольно условная, мы пока пользуемся в основном для написания экранов. Но итоговая версия библиотеки не будет иметь привязку ни к Андроиду, ни к экранам. А сама реализация от этого не меняется.
3. Классов действительно очень много, и это не совсем приятно. Мы облегчили себе работу тем, что написали плагин для кодогенерации. Еще можно вспомнить, что например в MVP у Presenter может быть fun onItemClick(item: Item), а в MVI вместо этого будет data class OnItemClick(val item: Item). Получается что в целом кода не становится больше из-за увеличения количество классов.
4. Все именно так, Data Store не обязательно хранилище данных, ограничения нет и если хочется можно работать в Actor с Repository или UseCase.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий