Питання Що таке MVP та MVC і яка різниця?


Дивлячись за межі RAD (перетягування та налаштування) спосіб побудови користувацьких інтерфейсів, який заохочує вас задіяти багато інструментів, ви, ймовірно, стикаються з трьома моделями дизайну Model-View-Controller, Model-View-Presenter і Model-View-ViewModel. Моє запитання має три частини:

  1. Які проблеми вирішують ці моделі?
  2. Як вони подібні?
  3. Як вони різні?

1839
2017-08-05 10:06


походження


mvc.givan.se/#mvp - givanse
IDK, але нібито для оригінального MVC, він мав бути використаний у малих. Кожна кнопка, ярлик тощо мала власний перегляд і об'єкт контролера, або, принаймні, це те, що дядько Боб заявляє. Я думаю, він говорив про Smalltalk. Шукайте свої розмови на YouTube, вони захоплюючі. - still_dreaming_1
MVP додає додатковий шар неорієнтованості, розділивши View-Controller на View і Presenter ... - the_prole
Основна відмінність полягає в тому, що у MVC Контролер не передає дані з Моделю у Вид. Він просто повідомляє View, щоб отримати дані з самої моделі. Проте в MVP немає зв'язку між View і Model. Сам Presenter сам отримує будь-які дані, необхідні від моделі, і передає його до перегляду, щоб показати. Більше до цього разом з зразком android у всіх архітектурних схемах тут: digigene.com/category/android/android-архітектура - Ali Nem


Відповіді:


Model-View-Presenter

В MVP, Presenter містить бізнес-логіку інтерфейсу користувача для перегляду. Всі виклики від представлення представлення безпосередньо до презентатора. Презентатор також відокремлений безпосередньо від перегляду та розмовляє з ним через інтерфейс. Це дозволить висміювати Погляд у тестовому приладі. Один з поширених ознак MVP полягає в тому, що має бути багато двосторонніх диспетчерських повідомлень. Наприклад, коли хтось натискає кнопку "Зберегти", обробник події делегує метод Presenter на "OnSave". Після того, як збереження буде завершено, Presenter потім викличе назад Вигляд через його інтерфейс, таким чином, щоб Перегляд міг відобразити, що збереження завершено.

MVP, як правило, є дуже природним засобом для досягнення роздільного представлення в Web Forms. Причиною є те, що вид завжди створюється спочатку за час виконання ASP.NET. Ти можеш Дізнайтеся більше про обидва варіанти.

Дві первинні варіації

Пасивний вигляд: Погляд настільки німий, наскільки це можливо, і містить майже нульову логіку. Презентатор - це середня людина, яка розповідає про Вид та модель. Вид та модель повністю захищені один від одного. Модель може посилювати події, але Presenter підписує їх для оновлення перегляду. У режимі пасивного перегляду немає прямих зв'язків даних, замість перегляду виставляються властивості setter, які Presenter використовує для встановлення даних. Вся держава керується в Presenter, а не на View.

  • Pro: максимальна поверхня випробування; чисте відокремлення Вид і Модель
  • Con: більше роботи (наприклад, всі властивості setter), оскільки ви виконуєте всі дані, обов'язкові для себе.

Наглядовий контролер: Презентатор обробляє жести користувача. Вид безпосередньо зв'язується з моделлю через зв'язування даних. У цьому випадку робота Презентатора полягає в тому, щоб відключити Модель від перегляду, щоб вона могла зв'язатись з нею. Ведучий також містить логіку для жестів, таких як натискання кнопки, навігації тощо.

  • Pro: використовуючи дані, кількість коду зменшується.
  • Con: там менше випробувальної поверхні (через зв'язування даних), і менше в інкапсуляції в представленні, оскільки він говорить безпосередньо до моделі.

Model-View-Controller

В MVC, Контролер несе відповідальність за визначення того, який Вигляд відображатиметься у відповідь на будь-яку дію, включаючи завантаження програми. Це відрізняється від MVP, де дії маршруту через View до Presenter. У MVC кожна дія у Погляді співвідноситься з викликом контролера разом з дією. В Інтернеті кожна дія пов'язана з викликом URL-адреси, з іншого боку, з яким відповідає Контролер. Після того, як Контролер завершить обробку, він поверне правильний вигляд. Послідовність продовжується таким чином протягом усього життя програми.

Дії у вікні перегляду
        -> дзвонити до контролера
        -> Логіка контролера
        -> Контролер повертає вигляд.

Ще одна велика різниця щодо MVC полягає в тому, що Вид не пов'язує безпосередньо з Моделлю. Точка зору просто виявляється, і вона абсолютно безвихідна. У реалізаціях MVC у звичайному вигляді, як правило, не буде логіки в коді. Це суперечить MVP, де це абсолютно необхідно, оскільки, якщо View не делегуватиме Presenter, він ніколи не буде викликаний.

Модель презентації

Ще один шаблон, щоб подивитися на це Модель презентації візерунок У цьому шаблоні немає Presenter. Замість View безпосередньо прив'язується до моделі презентації. Модель презентації - це модель, розроблена спеціально для перегляду. Це означає, що ця модель може виявляти властивості, які ніколи не ставитимуть до моделі домену, оскільки це буде порушенням розбіжностей. У цьому випадку Модель презентації зв'язується з моделлю домену та може підписатися на події, що надходять з цієї моделі. Потім Вигляд підписується на події, що надходять від моделі презентації, і відповідно оновлюється. Модель презентації може відображати команди, які використовується для перегляду дій. Перевага цього підходу полягає в тому, що ви можете по суті видалити код, що залишився, оскільки ПМ повністю інкапсулює всю поведінку для перегляду. Цей шаблон є дуже сильним кандидатом для використання в програмах WPF, і його також називають Model-View-ViewModel.

Є а Стаття MSDN про модель презентації і розділ в Посібник зі складання прикладних програм для WPF (колишня Призма) Розділені шаблони презентації


1803
2017-08-05 10:21



Чи можете ви прояснити цю фразу? Це відрізняється від MVP, де дії маршруту через View до Presenter. У MVC кожна дія у Погляді співвідноситься з викликом контролера разом з дією. Для мене це звучить так само, але я впевнений, що ви описуєте щось інше. - Panzercrisis
@Panzercrisis Я не впевнений, що це те, що мав на увазі автор, але це те, що я думаю, що вони намагаються сказати. Як і ця відповідь - stackoverflow.com/a/2068/74556 згадує, у MVC, контролери методів засновані на поведінці - іншими словами, ви можете картувати кілька переглядів (але однакову поведінку) до одного контролера. У MVP ведучий поєднується ближче до перегляду, і зазвичай це призводить до наближення, яке є ближче до один до одного, тобто дія перегляду відображає його відповідний метод ведучого. Зазвичай ви не вкажете дії іншого перегляду на інший метод ведучого (з іншого вигляду). - Dustin Kendall


Я згадав про це ще деякий час назад, цитуючи його Відмінний пост Тодда Снайдера про різницю між цими двома:

Ось основні відмінності між ними   закономірності:

Шаблон MVP

  • Вид більш вільно пов'язаний з моделлю. Ведучий є   відповідальний за прив'язку моделі до   погляд
  • Легше під'єднати тест через взаємодію з точкою зору   інтерфейс
  • Зазвичай переглядайте ведучу карту один на один. Можливо складні види   багато ведучих.

Шаблон MVC

  • Контролер заснований на поведінці, і його можна розділити по всій   погляди
  • Може бути відповідальним за визначення того, який вигляд відображатиметься

Це найкраще пояснення в Інтернеті, яке я міг знайти.


385
2017-07-06 22:18



Я не розумію, яким чином з точки зору можна зв'язати більш-менш тісно з моделлю, коли в обох випадках цілком слід повністю розділити їх. Я не маю на увазі, що ви сказали щось не так - просто заплуталися щодо того, що ви маєте на увазі. - Bill K
@pst: з MVP це дійсно 1 View = 1 Presenter. За допомогою MVC Контролер може керувати кількома переглядами. Це дійсно. За допомогою моделі "вкладиш" уявіть кожну вкладку, що має свій власний презентатор, на відміну від наявності одного контролера для всіх вкладок. - Jon Limjap
Спочатку існує два типи контролерів: те, що, як ви сказали, поділяєте між різними представленнями, а також ті, хто має певні види, головним чином призначені для адаптації інтерфейсу спільного контролера. - Acsor
@JonLimjap Що це означає за одним видом у будь-якому разі? У контексті програмування iOS це односхемний? Це робить контролер iOS більш схожим на MVP, чим MVC? (З іншого боку, ви також можете мати кілька контролерів iOS на екран) - huggie
Добре, малюнкова малюнка Тодда з MVC повністю суперечить ідеї відокремити View and Model. Якщо ви подивитесь на діаграму, то воно відображатиметься в розділі "Моделі оновлень" (стрілка від моделі до вигляду). У якому Всесвіті це система, де Модель безпосередньо взаємодіє з View, відокремлений ?? - Ash


Це надмірне спрощення багатьох варіантів цих моделей дизайну, але так я люблю думати про відмінності між ними.

MVC

MVC

MVP

enter image description here


367
2017-09-12 20:47



Це відмінне зображення схеми, що показує абстракцію та повну ізоляцію будь-якого графічного інтерфейсу, пов'язаного (перегляду матеріалу) з API ведучого. Одне незначне питання: майстер-презентатор може використовуватися там, де є лише один ведучий, а не один для кожного перегляду, але ваша схема є найчистішою. ІМО, найбільша відмінність MVC / MVP полягає в тому, що MVP намагається залишити вигляд повністю позбавленим нічого іншого, окрім відображення поточної "стану перегляду" (перегляду даних), а також заборонити перегляду будь-яким знанням про об'єкти Model. Таким чином, інтерфейси, що потребують бути там, повинні ввести цей стан.
Хороша картина. Я використовую MVP досить багато, тому я хотів би зробити одне питання. На мій досвід, Презентаторам доводиться часто спілкуватися один з одним. Те саме стосується моделей (або бізнес-об'єктів). Через ці додаткові "сині лінії" спілкування, які будуть у вашому малюнку MVP, відносини Presenter-Model можуть стати досить заплутаними. Тому я намагаюся підтримувати взаємовідносини між моделлю Presenter-Model та "один-до-багатьом". Так, для роботи моделі потрібні додаткові методи делегування, але це зменшує більшість головних болів, якщо змінюється API моделі чи потребує рефакторинг. - splungebob
Приклад MVC неправильний; існує суворе співвідношення 1: 1 між представленнями та контролерами. За визначенням, контролер інтерпретує введення людського жесту для створення подій для моделі та перегляду для одного елемента керування. Простіше кажучи, MVC призначений для використання лише з окремими віджетами. Один віджет, один вид, один елемент керування. - Samuel A. Falvo II
@ SamuelA.FalvoII не завжди є 1: Багато хто з контролерів і переглядів в ASP.NET MVC: stackoverflow.com/questions/1673301/... - StuperUser
@StuperUser - Не впевнений, що я думав, коли я це написав. Звичайно, ти маєш рацію, і, оглядаючись на те, що я написав, я мушу дивуватися, чи маю я якийсь інший контекст, який я не зміг сформулювати. Дякую за корекцію. - Samuel A. Falvo II


Ось ілюстрації, які представляють комунікаційний потік

enter image description here 

enter image description here


210
2017-08-25 21:22



У мене є питання щодо діаграми MVC. Я не отримую ту частину, в якій вигляд виходить, щоб отримати дані. Я думаю, що контролер буде надсилати дані з потрібними даними. - Brian Rizo
Якщо користувач натискає кнопку, як це не взаємодіє з представленням? Я відчуваю себе як у MVC, користувач взаємодіє з представленням більше, ніж контролер - Jonathan
Я знаю, що це стара відповідь, але чи може хтось відповісти на точку @JonathanLeaders? Я йду з фону winforms, якщо ви не зробили якийсь дуже унікальне кодування, коли ви натискаєте користувальницький інтерфейс / вигляд отримує знання про цей клік, перш ніж щось інше. Принаймні, наскільки я знаю? - Rob P.
@ ROBP Я думаю, ці типи діаграм завжди схильні бути або занадто складними, або занадто простими. Імпо потоку діаграми MVP також справедливо для застосування MVC. Можливо варіації залежно від функцій мови (зв'язування даних / спостерігач), але в підсумку ідея полягає в тому, щоб відокремити представлення від даних / логіки програми. - Luca Fülbier
@ JonathanLeaders Люди мають дійсно що говорять про "MVC". Особа, яка створила цю діаграму, мабуть, мала на увазі класичний веб-MVC, де "введення користувача" - це запити HTTP, а "представлення даних, що повертається користувачеві" - це рендеризована HTML-сторінка. Таким чином, будь-яка взаємодія між користувачем та представленням "не існує" з точки зору автора класичного додатку Web MVC. - cubuspl42


MVP є ні обов'язково такий сценарій, за яким відповідає вид (див., наприклад, MVP Taligent).
Я вважаю жаль тим, що люди все ще проповідують це як візерунок (вигляд відповідає), на відміну від анти-схеми, оскільки це суперечить "Це просто думка" (Pragmatic Programmer). "Це лише вигляд" свідчить, що кінцевий вигляд, показаний користувачеві, є другорядною проблемою програми. MVP-модель Microsoft робить повторне використання Переглядів значно складнішим і зручно виправдовує розробника Microsoft заохочення поганої практики.

Щоб бути абсолютно відвертими, я думаю, що основні проблеми MVC залишаються вірними для будь-якої реалізації MVP, і відмінності майже цілком смислові. Поки ви відстежуєте розбіжності між представленням (який відображає дані), контролер (який ініціалізує та контролює взаємодію з користувачем) та модель (основні дані та / або служби)), ви скористаєтеся перевагами MVC . Якщо ви користуєтесь перевагами, то хто дійсно піклується про те, чи є ваш шаблон MVC, MVP або контрольний контролер? Єдиний реальний малюнок залишається як MVC, решта просто відрізняються смаками цього.

Розглянемо це дуже цікава стаття, яка всебічно перераховує ці різні варіанти реалізації. Ви можете помітити, що всі вони в основному роблять те ж саме, але дещо по-іншому.

Я особисто вважаю, що MVP нещодавно був знову представлений як захоплюючий термін, щоб або зменшити аргументи між семантичними фанатиками, які стверджують, щось дійсно є MVC чи ні, або для обґрунтування інструментів розробки швидкого застосування Microsoft. Жодна з цих причин у моїх книгах не виправдовує її існування як окремого шаблону дизайну.


149
2017-08-06 22:51



Я прочитав кілька відповідей та блогів про відмінності між MVC / MVP / MVVM / і т. Д. " По суті, коли ви займаєтесь бізнесом, це все одно. Це не має значення, чи є у вас інтерфейс чи ні, і чи використовуєте ви встановлювач (або будь-яку іншу мовну функцію). Здається, що різниця між цими моделями виникла через відмінність реалізації різних рамок, а не від поняття. - Michael
Я б не назвав MVP а анти-візерунок, як пізніше в повідомленні "... решта [включаючи MVP] - це просто відмінні смаки від [MVC] ..", що означало б, що якщо MVP був анти-шаблоном, то був і MVC ... це просто смак для підхід іншої структури. (Тепер, деякі конкретний Реалізація MVP може бути більш-менш бажаною, ніж деякі конкретний Реалізація MVC для різних завдань ...)
@Quibblsome: "Я особисто думаю, що MVP тільки нещодавно був знову представлений як захоплюючий термін, щоб або зменшити аргументи між семантичними фанатиками, які стверджують, що щось дійсно MVC чи ні [...] Жодна з цих причин в моїх книгах не виправдовує його існування як окремий візерунок дизайну ". Він досить відрізняється, щоб зробити його виразним. У MVP вигляд може бути будь-яким, що виконує попередньо визначений інтерфейс (View in MVP є автономним компонентом). У MVC Контролер створюється для певного вигляду (якщо параметри відношення можуть змусити когось відчути, що це коштує іншого терміну). - Hibou57
@ Hibou57, немає нічого, щоб зупинити MVC посилатися на вигляд як на інтерфейс або створити загальний контролер для декількох різних поглядів. - Quibblesome
@quibblesome насправді є. Контролери, за визначенням, тісно пов'язані зі своїми відповідними думками, тому що їхня робота полягає в тлумаченні жестів людини (натискання клавіш, оновлення миші тощо) у події для індивідуальне управління на вікні Ось чому у вас є суворий один контролер, одне відношення до подання. Контролери були ніколи призначений для широкого використання. Для широкомасштабного використання застосовано модель Application (aka Presentation Model), що найкраще підходить для цієї мети. Оскільки графічні інтерфейси, не для Smalltalk, не покладаються на MVC для здійснення контролю, MVC практично не має сенсу. - Samuel A. Falvo II


MVP: погляд відповідає.

Погляд, в більшості випадків, створює його ведучий. Ведучий буде взаємодіяти з моделлю та керувати представленням через інтерфейс. Погляд іноді взаємодіє з ведучим, як правило, через деякий інтерфейс. Це зводиться до реалізації; ви хочете, щоб виклик викликав методи до ведучого або ви хочете, щоб у перегляді були події, які провідник слухає? Це зводиться до цього: Погляд знає про ведучого. Погляд делегує ведучого.

MVC: відповідальний контролер.

Контролер створюється або доступ здійснюється на основі певного події / запиту. Після цього контролер створює відповідний вигляд та взаємодіє з моделлю для подальшого налаштування вигляду. Це зводиться до: контролер створює та управляє виглядом; погляд є підлеглим контролеру. Погляд не знає про контролер.


90
2017-12-20 02:10



"Перегляд не знає про контролер". Я думаю, ви маєте на увазі, що ця точка зору безпосередньо не стосується моделі? - Lotus Notes
Погляд ніколи не повинен знати про модель в один з них. - Brian Leahy
@ Брайан: "Вигляд, у більшості випадків, створює його Presenter". У більшості випадків я бачив протилежне, коли Presenter запускає і модель, і вид. Щоправда, у перегляді також може запустити Presenter, але цей момент насправді не є самим відмінним. Найгостріше трапляється пізніше протягом життя. - Hibou57
Можливо, ви захочете відредагувати свою відповідь, щоб пояснити далі: оскільки Ревізор не знає про Контролер, як здійснюються дії користувача, які виконуються на "візуальних" елементах, які користувач бачить на екрані (тобто "Перегляд"), повідомляється Контролерові ... - Ash


enter image description here

MVC (контролер моделі перегляду)

Вхід спрямовується спочатку на Контролер, а не на перегляд. Цей вхід може надходити від користувача, який взаємодіє з сторінкою, але може також полягати в простому введенні певної URL-адреси в браузер. У будь-якому випадку це контролер, який взаємодіє з деякими функціональними можливостями. Між контролером та представленням існує взаємозв'язок "багато-на-один". Це тому, що один контролер може вибирати різні види, які будуть відтворюватися на основі виконуваної операції. Зверніть увагу на стрілку в один шлях від контролера до перегляду. Це тому, що View не має ніяких знань або посилання на контролер. Контролер повертає модель, тому існує знання між представленням Перегляду та очікуваною моделлю, але не контролером, який його обслуговує.

MVP (презентатор моделі перегляду)

Введення починається з перегляду, а не в Presenter. Існує взаємозв'язок "один-к-одному" між представленням перегляду та пов'язаним з ним презентатором. У перегляді міститься посилання на презентатора. Презентатор також реагує на події, що відбуваються з представлення даних, тому він знає, як виглядати його пов'язано з. Презентатор оновлює представлення даних на основі затребуваних дій, які він виконує у моделі, але вигляд не є моделлю.

Для більш Посилання


62
2017-08-05 10:22



Але в Росії MVP шаблон, коли пристрій завантажується в перший раз, чи не провідник несе відповідальність за завантаження першого вигляду? Як, наприклад, коли ми завантажуємо facebook applicaiton, чи не є ведучим, відповідальним за завантаження сторінки входу? - viper
Посилання від моделі до перегляду в MVC? Можливо, ви захочете відредагувати свою відповідь, щоб пояснити, як це робить його "відокремленою" системою, з огляду на це посилання. Підказка: вам може здатися важко. Крім того, якщо ви не думаєте, що читач із задоволенням погодиться з тим, що вони погано обчислювали все своє життя, ви можете розказати, чому дії першими виконуються за допомогою контролера в MVC, незважаючи на те, що користувач взаємодіє з "візуальними" елементами на екрані (тобто Вид), а не якийсь абстрактний шар, що сидить позаду обробки. - Ash
Це має бути прийнята відповідь. чіткий і стислий - Nelson Ramirez


  • MVP = Model-View-Presenter
  • MVC = Model-View-Controller

    1. Обидва моделі презентації. Вони відокремлюють залежності між Моделлю (думають об'єкти домену), вашим екраном / веб-сторінкою (Перегляд) та способом роботи вашого інтерфейсу (Presenter / Controller)
    2. Вони досить схожі на поняття, люди ініціалізують Presenter / Controller по-різному в залежності від смаку.
    3. Відмінна стаття про відмінності тут. Найбільш помітним є те, що модель MVC має Модель оновлення View.

31
2017-08-08 05:55



Модель оновлення VIew. І це все-таки відокремлена система? - Ash


Також варто пам'ятати, що існують і різні типи MVP. Фаулер розбив візерунок на два - пасивний режим перегляду та контрольний контролер.

Під час використання пасивного перегляду тип перегляду зазвичай реалізує дрібнозернистий інтерфейс із властивостями, які більше або менше посилаються безпосередньо на віджет інтерфейсу підкласу. Наприклад, у вас може бути ICustomerView із такими властивостями, як Ім'я та Адреса.

Ваша реалізація може виглядати приблизно так:

public class CustomerView : ICustomerView
{
    public string Name
    { 
        get { return txtName.Text; }
        set { txtName.Text = value; }
    }
}

Клас Presenter буде поговорити з моделлю і "поставити" його в режим перегляду. Цей підхід називається "Пасивний вигляд". Перевага полягає в тому, що його легко перевірити, і його простіше переміщати між платформами інтерфейсу користувача (веб, Windows / XAML тощо). Недоліком є ​​те, що ви не можете використовувати такі засоби, як наведення даних (тобто дійсно потужний в рамах, як WPF і Silverlight)

Другим ароматом MVP є Наглядовий Контролер. У такому випадку у вашому перегляді може бути властивість, що називається Клієнт, а потім знову відображається для віджетів інтерфейсу користувача. Вам не доведеться думати про синхронізацію та керування мікро-представленням даних, а контрольний контролер може входити та допомагати, коли це потрібно, наприклад, за допомогою логіки зв'язаної взаємодії.

Третій "аромат" MVP (або хтось, можливо, називає це окремою схемою) - модель презентації (або іноді називається Modell-View-ViewModel). У порівнянні з MVP ви «об'єднаєте» M і P в один клас. У вас є ваш об'єкт клієнта, до якого приєднуються ваші дані інтерфейсу користувача, але у вас також є додаткові користувальницькі поля, такі як "IsButtonEnabled", "IsReadOnly" тощо.

Я думаю, що найкращий ресурс, який я знайшов для архітектури інтерфейсу користувача, - це серія повідомлень блогу, зроблених Джеремі Міллером Створіть свою власну Серію CAB Зміст. Він охоплює всі аромати MVP і показує код C # для їх реалізації.

Я також відправив в блог про шаблон Model-View-ViewModel в контексті Silverlight за адресою YouCard Повторно відвідано: впровадження шаблону ViewModel.


31
2018-04-06 13:51





Є багато відповідей на запитання, але я відчував, що потрібна деяка дійсно проста відповідь, явно порівнюючи ці два. Ось дискусія, яку я склав, коли користувач шукає назву фільму в додатку MVP та MVC:

Користувач: натисніть кнопку ...

Вид: Хто це? [MVP|MVC]

Користувач: я просто натиснув кнопку пошуку ...

Вид: Добре, тримайся секунди ... [MVP|MVC]

( Вид зателефонувавши Ведучий|Контролер ...) [MVP|MVC]

Вид: Привіт! Ведучий|Контролер, користувач щойно натиснув кнопку пошуку, що я повинен робити? [MVP|MVC]

Ведучий|Контролер: Привіт! Вид, чи існує будь-який пошуковий термін на цій сторінці? [MVP|MVC]

Вид: Так, ... це ... "піаніно" [MVP|MVC]

Ведучий: Дякую Вид..., тим часом я шукаю пошуковий термін на Модель, будь ласка, покажіть йому / її індикатор виконання [MVP|MVC]

( Ведучий|Контролер називає Модель ...) [MVP|MVC]

Ведучий|Контролер: Привіт! Модель, Чи є у вас відповідність для цього пошукового терміна ?: "piano" [MVP|MVC]

Модель: Привіт! Ведучий|Контролер, дай мені перевірити … [MVP|MVC]

( Модель робить запит до бази даних фільмів ...) [MVP|MVC]

( Згодом ... )

-------------- Тут MVP та MVC починають розходитися ---------------

Модель: Я знайшов для вас список Ведучий, тут він знаходиться в JSON "[{" ім'я ":" Піаніно вчитель "," рік ": ​​2001), (" ім'я ":" Піаніно "," рік ": ​​1993)]"MVP]

Модель: Є певний результат, доступний, Контролер. Я створив змінну поля в моєму випадку і наповнив його результатом. Це ім'я - "searchResultsList" [MVC]

(Ведучий|Контролер Дякую Модель і повертається до Вид) [MVP|MVC]

Ведучий: Дякую за чекання Вид, Я знайшов список відповідних результатів для вас і влаштував їх у презентабельному форматі: ["Piano Teacher 2001", "Piano 1993"]. Покажіть його користувачеві у вертикальному списку. Також, будь ласка, приховайте панель прогресу зараз [MVP]

Контролер: Дякую за чекання ВидЯ запитував Модель про ваш пошуковий запит. Він стверджує, що знайшов список відповідних результатів і зберігав їх у змінній з ім'ям "searchResultsList" всередині його екземпляра. Ви можете отримати його звідти. Також, будь ласка, приховайте панель прогресу зараз [MVC]

Вид: Велике спасибі Ведучий [MVP]

Вид: Дякую "Контролер" [MVC] (Тепер Вид Сам себе піддає сумніву: як мені представити результати, які я отримую від Модель користувачеві? Якщо рік виробництва кіно стане першим чи останнім ...? Чи має бути він у вертикальному або горизонтальному списку? ...)

Якщо ви зацікавлені, я написав серію статей, що стосуються архітектурних прикладів додатків (MVC, MVP, MVVP, чиста архітектура, ...) у супроводі Github repo тут. Хоча зразок написано для android, основні принципи можуть бути застосовані до будь-якого середовища.


18
2017-08-05 10:20