Как комуникирате между презентатор и изглед в MVP схема?

По принцип има два варианта, доколкото знам.

Първият е събития за излагане на известия, за които презентаторът трябва да бъде абониран. Когато потребител щракне върху някакъв бутон в изгледа, изгледът просто задейства някакво събитие, уведомява, че нещо е променено.

Второто е просто да използвате модел на наблюдател и да оставите водещия да се намеси в някакъв договор. Нека бъде интерфейс с методи като събития, които ви казах по-горе. Към изгледа трябва да бъде прикрепен водещ-наблюдател.

Като Джереми Милър в легендарния му "Създайте своя собствена серия CAB" публикации в блога казаха, че е по-добре за него да използва втората опция.

Какво е вашето мнение по тази тема? Как обвързвате презентатора и изгледа във вашите проекти? Какви са предимствата или недостатъците на всяка опция?

Нека направим анкета тук. Мисля, че би било полезно. Благодаря предварително!


За да отговорите на отговора на Питър Ричи.

Проблемът ми е, че нямам опит и трябва да разчитам на нечие мнение, за да взема решение и да избера начин, който ми се струва правилен.

Недостатъкът на интерфейсите е, че имате специфично свързване. Изгледът е свързан с интерфейс и нещо трябва да реализира този интерфейс

Но от друга страна, събитията не служат ли като някакъв договор (както интерфейсът)? Той обвърза водещия с изгледа, както трябва да реагира на тези събития.


person kseen    schedule 12.05.2012    source източник
comment
събитията са по-свободен договор. Абонирате се за събитие с делегат; това може да бъде публичен метод, частен метод, анонимен метод и т.н. С интерфейс, той трябва да внедри този интерфейс като публични методи.   -  person Peter Ritchie    schedule 12.05.2012


Отговори (1)


Наблюдателят може да бъде малко досаден. Ако имате няколко контроли, които генерират събития или няколко събития, тогава трябва да ги свържете едно по едно. Докато ако използвате интерфейс, всичко е на едно място и получавате грешки при безопасността на типа и компилирането, ако забравите да внедрите конкретен член на интерфейса. Недостатъкът на интерфейсите е, че имате специфично свързване. Изгледът е свързан с интерфейс и нещо трябва да реализира този интерфейс. можете да използвате сегрегация на интерфейса, за да ограничите свързването на интерфейса до един специфичен клас; но това добавя известно ниво на сложност.

Няма един правилен отговор за това; има ли критерии, които можете да предложите, за да помогнете при решението си?

person Peter Ritchie    schedule 12.05.2012
comment
@Peter Ritchie, можеш ли да хвърлиш малко светлина върху това как трябва да се комуникира от model към presenter, така че presenter да може да извърши някакво действие на view. например, да речем, четенето на базата данни се извършва в model тогава, как трябва model да каже на presenter, че е прочел данните и да предаде обратно данните на presenter, така че presenter да може да актуализира view - person eRaisedToX; 25.05.2017
comment
@eRaisedToX Жизненоважно е моделът да бъде възможно най-слабо свързан с водещия (теоретично не можете напълно да отделите нещо от нещо, което го използва). Това се прави с типични техники за абстракция и капсулиране. Както споменах по-горе, един от начините е ефективното използване на инверсия на зависимости и зависимост от интерфейси (абстракции), вместо директно от презентатор или конкретен презентатор. Но това означава, че представящият трябва да има екземпляр на този интерфейс, за да го извика. Друг вид абстракция е посредничеството в комуникацията между... - person Peter Ritchie; 25.05.2017
comment
...моделът и водещият чрез някакъв вид прокси. Често виждаме, че това се прилага с опашки за съобщения, но това не означава използване на междинен софтуер. Например, обикновено UI рамките комуникират от изгледа към приложенията чрез съобщения - което е начин за отделяне на UI рамката от всяко конкретно действие - без да се използва междинен софтуер. Много харесвам този тип отделяне, намирам го за много гъвкав. Така че един модел може да комуникира с други неща чрез поставяне на съобщения на опашка (която може просто да бъде екземпляр на ConcurrentQueue). - person Peter Ritchie; 25.05.2017
comment
Благодаря много за вашия ценен коментар..! Наистина би помогнало. - person eRaisedToX; 26.05.2017