I
Суть то в общении через интерфейсы
Size: a a a
2017 January 31
I
Есть интерфейс, значит проблем с заменой нет
AZ
Разве с обычным мвп у нас будут проблемы при замене каких-то частей?
мвп тут нипричем, неважно как будет организован слой представления, вы не можете выкинуть слой представления и подставить другой, не затронув при этом слой с бизнес-логикой
I
мвп тут нипричем, неважно как будет организован слой представления, вы не можете выкинуть слой представления и подставить другой, не затронув при этом слой с бизнес-логикой
могу. они не зависят друг от друга. какая разницп бизнеслогике кто получит респонс по колбеку?
I
или я не понимаю сути
AZ
в слое бизнес-логики есть связь со слоем UI
если поменять UI то придется менять бизнес логику, точнее придется туда лезть
import com.matsyuk.testablecodemobius.ui.profile.models.PersonalFullDataModel;
если поменять UI то придется менять бизнес логику, точнее придется туда лезть
AZ
ну это больше с академической точки зрения, на практике конечно не все так категорично)
I
ну от модели абстрагироваться уж явно никак не выйдет
AZ
можно маппить эти модели не в интеракторе, а в UI слое или модель можно объявить в слое с бизнес-логикой
AZ
можно сделать так, чтобы с слой с бизнес логикой не имел ни единой ссылки на UI или Data, это не так сложно) просто автор явно откзался от этого, я хочу понять какие профиты он от этого получает
I
только ради чего, не совсем ясно)
AZ
ну у меня был один потенциальный кейс, который в итоге не пришлось реализовывать) просто это стандарт вроде как
EM
@eugene_matsyuk Здесь уже кажется обсуждали ваши архитектурные решения, но я хотел дополнительно задать вам вопрос.
В большинстве литературы и опенсорсах трехуровневая архитектрура (слой пользовательского интерфейса (представления), слой бизнес-логики, слой доступа к данным) представлена следующей схемой зависимостей: слой пользовательского интефейса зависит от слоя бизнес - логики, слой доступа к данным зависит от слоя бизнес-логики, бизнес-логика не зависит ни от одного слоя (presentation -> domain <- data). Если говорить об андроиде, то слой пользовательского интерфейса (представления) будет знать о всех слоях, которые есть в приложении, так как в этом слое происходит связываение всех зависимостей в приложении.
Профит от такого подхода, конечно в реалиях, это возможно будет не настолько просто, но усилий нужно приложить меньше, чем при других подходах:
1. Можем заменить пользовательский интерфейс не затронув другие слои
2. Можем заменить библоиотеку доступа к данным не затронув другие слои
3. Бизнес-логика является ядром приложения и без лишних зависимостей может быть перенесена куда угодно, другое приложение, другая платформа и т.д.
Насколько я понял из доклада, у вас IRepository и Repository в слое доступа к данным, получается инверсии зависимостей между слоями нет и бизнес-логика зависит от слой доступа к данным. В вашей схеме интеракторы занимаются маппингом в UI модели, получается, что они знают про слой пользовательского интерфейса.
В итоге схема зависимостей у вас примерно такая presentation <--> domain -> data. Что теоретически лишает вас некоторых вышеперечисленных профитов.
Расскажите о том, что послужило поводом для такого решения, какие преимущества у вашего подхода и почему не используете вышеупомянутую схему зависимостей? Должен признаться, пока ни одним из профитов архитектуры, которые перечислил не приходилось воспользоваться, но это стандартное решение.
В большинстве литературы и опенсорсах трехуровневая архитектрура (слой пользовательского интерфейса (представления), слой бизнес-логики, слой доступа к данным) представлена следующей схемой зависимостей: слой пользовательского интефейса зависит от слоя бизнес - логики, слой доступа к данным зависит от слоя бизнес-логики, бизнес-логика не зависит ни от одного слоя (presentation -> domain <- data). Если говорить об андроиде, то слой пользовательского интерфейса (представления) будет знать о всех слоях, которые есть в приложении, так как в этом слое происходит связываение всех зависимостей в приложении.
Профит от такого подхода, конечно в реалиях, это возможно будет не настолько просто, но усилий нужно приложить меньше, чем при других подходах:
1. Можем заменить пользовательский интерфейс не затронув другие слои
2. Можем заменить библоиотеку доступа к данным не затронув другие слои
3. Бизнес-логика является ядром приложения и без лишних зависимостей может быть перенесена куда угодно, другое приложение, другая платформа и т.д.
Насколько я понял из доклада, у вас IRepository и Repository в слое доступа к данным, получается инверсии зависимостей между слоями нет и бизнес-логика зависит от слой доступа к данным. В вашей схеме интеракторы занимаются маппингом в UI модели, получается, что они знают про слой пользовательского интерфейса.
В итоге схема зависимостей у вас примерно такая presentation <--> domain -> data. Что теоретически лишает вас некоторых вышеперечисленных профитов.
Расскажите о том, что послужило поводом для такого решения, какие преимущества у вашего подхода и почему не используете вышеупомянутую схему зависимостей? Должен признаться, пока ни одним из профитов архитектуры, которые перечислил не приходилось воспользоваться, но это стандартное решение.
Фундаментально.
Спасибо за вопрос)
Предлагаю завтра уже обсудить, ибо тут надо мне подумать)
Спасибо за вопрос)
Предлагаю завтра уже обсудить, ибо тут надо мне подумать)
I
дайте уж ссылку тогда
I
раз такая пьянка
AZ
Фундаментально.
Спасибо за вопрос)
Предлагаю завтра уже обсудить, ибо тут надо мне подумать)
Спасибо за вопрос)
Предлагаю завтра уже обсудить, ибо тут надо мне подумать)
ок!
AZ
дайте уж ссылку тогда
на что ссылку?
I
ну что за репо обсуждается
I
или выступление
