Comments 6
Спасибо за Dagger2. Очень интересная идея кодогенерации для реализации DI
А мне вот в Dagger 2 не понравилось то, что setupComponents() нужно реализовывать в каждой activity/fragment. Нельзя просто взять и вынести этот код в базовый класс activity/fragment. Он просто не будет работать и инъектить зависимости
MVP — это паттерн, который позволяет разбивать приложение на три основных слоя (компонента):
MVP (как и MVC, MVVM, MVPVM) — это всего лишь UI-паттерн, находящийся на границе приложения. Такой паттерн не может «разбивать приложение на три основных слоя». Эти паттерны не описывают архитектуру приложений (хоть и оказывают влияние), это всего лишь UI-boundary patterns. Я понимаю, что вы имели ввиду, но хотелось всё же указать на то, что так говорить некорректно.
Как раз говорить, как говорите вы, некорректно. Какие же это UI паттерны? Что значит граница приложения? Где можно почитать про то, что это всё вместе UI-паттерн?
Мне всегда казалось, что это архитектурные паттерны.
В MVC (к примеру) модель, UI и схема их взаимодействия разделены.
Основная цель применения этой концепции состоит в разделении бизнес-логики (модели) от её визуализации (представления, вида).
Т.е. они используются для грамотного разделения модели и UI, это очевидно.
Разделять приложение на слои (я даже не говорю про разделение на уровни в рамках одного слоя) и нужно, если следовать данным архитектурным паттернам.
Мне всегда казалось, что это архитектурные паттерны.
В MVC (к примеру) модель, UI и схема их взаимодействия разделены.
Основная цель применения этой концепции состоит в разделении бизнес-логики (модели) от её визуализации (представления, вида).
Т.е. они используются для грамотного разделения модели и UI, это очевидно.
Разделять приложение на слои (я даже не говорю про разделение на уровни в рамках одного слоя) и нужно, если следовать данным архитектурным паттернам.
Sign up to leave a comment.
Вариант реализации MVP + DI(Dagger 2) в Android