Яка різниця між MVC та MVVM? [зачинено]

Чи є різниця між стандартною схемою "Контролер перегляду моделі" та моделлю "Модель / Вид / Перегляд / Модель" Microsoft?

MVC / MVVM не є або / або вибір.

Обидві моделі по-різному з'являються в розробці ASP.Net та Silverlight / WPF.

Для ASP.Net MVVM використовується для двостороннього прив'язування даних усередині представлень. Зазвичай це реалізація на стороні клієнта (наприклад, використання Knockout.js). MVC, з іншого боку, є способом розділення проблем на стороні сервера .

Для Silverlight та WPF модель MVVM є більш охоплюючою і може здаватися, що вона виступає заміною MVC (або інших моделей організації програмного забезпечення на окремі обов'язки). Одне припущення, що часто виходили з цього малюнка, в тому , що ViewModelпросто замінити контролер в MVC(як якщо б ви могли б просто замінити VMна Cв абревіатурі , і все буде прощено) ...

ViewModel не обов'язково замінює потребу в окремих контролерах.

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

* Примітка: на практиці контролери видаляють більшу частину логіки з ViewModel, що вимагає тестування одиниць. Потім VM стає німим контейнером, який вимагає невеликих, якщо такі є, тестувань. Це добре, оскільки VM - це просто міст, між дизайнером і кодером, тому слід зберігати простоту.

Навіть у MVVM контролери, як правило, містять усю логіку обробки та вирішують, які дані відображатимуть у яких переглядах, використовуючи які моделі перегляду.

З того, що ми бачили до цього часу, головна перевага шаблону ViewModel - видалення коду з коду XAML, щоб зробити редагування XAML більш незалежною задачею . Ми все ще створюємо контролери, як і коли це потрібно, щоб контролювати (не каламбур) загальну логіку наших програм.

Основні рекомендації щодо MVCVM, яких ми дотримуємось:

• Перегляди відображають певну форму даних . Вони не мають уявлення, звідки беруться дані.
• ViewModels містять певну форму даних і команд , вони не знають, звідки беруться дані чи код або як вони відображаються.
• Моделі містять фактичні дані (різні контексти, зберігання чи інші методи)
• Контролери слухають і публікують події. Контролери забезпечують логіку, яка контролює, які дані бачать і де. Контролери надають коду команди ViewModel, щоб ViewModel фактично використовувався повторно.

Ми також відзначили, що рамка коду Sculpture реалізує MVVM та зразок, подібний до Prism AND, а також широко використовує контролери для розділення логіки всіх випадків використання.

Не припускайте, що контролери застаріли в моделях View.

Я розпочав блог на цю тему, до якого я додам, як і коли зможу . Існують проблеми при поєднанні MVCVM із загальними навігаційними системами, оскільки більшість навігаційних систем просто використовують Views і VM, однак я пізнаю це в наступних статтях.

Додатковою перевагою використання моделі MVCVM є те, що в житті пам'яті необхідно існувати лише об'єкти контролера протягом життя програми, а контролери містять в основному дані про код і мало стану (тобто мініатюрні накладні витрати). Це робить значно меншими обсяги пам’яті додатків, ніж рішення, де моделі перегляду мають бути збережені, і це ідеально підходить для певних типів мобільних розробок (наприклад, Windows Mobile за допомогою Silverlight / Prism / MEF). Це, звичайно, залежить від типу програми, оскільки вам може знадобитися зберігати час від часу кешовані віртуальні машини для чутливості.

Примітка. Ця публікація неодноразово редагувалася, і вона не була спеціально націлена на вузьке запитання, тому я оновив першу частину, щоб тепер висвітлити і це. Значна частина обговорень у коментарях нижче стосується лише ASP.Net, а не широкої картини. Ця публікація мала на меті охопити ширше використання MVVM у Silverlight, WPF та ASP.Net та спробувати відмовити людей від заміни контролерів ViewModels.

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

По мірі їх складності в середині 2000-х років модель дизайну програмного забезпечення MVC - вперше описана в 1970-х - почала застосовуватися до веб-додатків. Подумайте між базами даних, HTML-сторінками та кодом. Давайте ще раз уточнимо це, щоб прибути до MVC: Для »бази даних», припустимо, база даних плюс код інтерфейсу. Для "HTML-сторінок" припустимо шаблони HTML плюс код для обробки шаблонів. Для "коду між", припустимо, що зіставлення кліків користувачем натискає на дії, можливо, впливаючи на базу даних, безумовно, спричиняючи відображення іншого перегляду. Ось це, принаймні, для цього порівняння.

Давайте збережемо одну особливість цього веб-матеріалу, не такий, як це є сьогодні, але як він існував десять років тому, коли JavaScript був низьким, зневажливим роздратуванням, від якого справжні програмісти добре відмовилися: Сторінка HTML по суті німа і пасивна . Браузер - це тонкий клієнт, або, якщо ви хочете, поганий клієнт. У браузері немає інтелекту. Правило перезавантаження повної сторінки. "Вид" формується заново кожного разу.

Згадаймо, що цей веб-спосіб, незважаючи на всю лють, був жахливо відсталим порівняно з робочим столом. Настільні програми - це товсті клієнти або багаті клієнти, якщо ви хочете. (Навіть таку програму, як Microsoft Word, можна розглядати як якийсь клієнт, клієнт для документів.) Вони - клієнти, сповнені інтелекту, повні знання про свої дані. Вони величні. Вони кешують дані, якими вони обробляють в пам'яті. Немає такого лайна, як повне перезавантаження сторінки.

І цей багатий настільний спосіб, мабуть, звідки виникла друга абревіатура - MVVM. Не обманюйте букви, опускаючи C. Контролери все ще є. Вони повинні бути. Нічого не знімається. Ми лише додамо одне: завзятість, кешовані дані про клієнта (і разом з ним інтелект для обробки цих даних). Ці дані, по суті кеш-пам'ять клієнта, тепер називаються «ViewModel». Це те, що дозволяє наситити інтерактивність. І це все.

• MVC = модель, контролер, вид = по суті одностороння комунікація = погана інтерактивність
• MVVM = модель, контролер, кеш, перегляд = двостороння комунікація = багата інтерактивність

Ми можемо побачити, що за допомогою Flash, Silverlight та - найголовніше - JavaScript, Інтернет охопила MVVM. Веб-переглядачі вже не можна законно називати тонкими клієнтами. Подивіться на їх програмованість. Подивіться на їх споживання пам’яті. Подивіться на всю інтерактивність Javascript на сучасних веб-сторінках.

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

MVVM Model-View ViewModel схожий на MVC, Controller-View Controller

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

Рассел Схід веде блог, де детальніше обговорюється Чому MVVM відрізняється від MVC

З одного боку, MVVM - це прогресування структури MVC, яка використовує XAML для обробки дисплея. Ця стаття окреслює деякі аспекти двох.

Основна мета архітектури Model / View / ViewModel здається в тому, що поверх даних ("Модель") є ще один шар невізуальних компонентів ("ViewModel"), які більш чітко відображають поняття даних. до понять подання даних ("Вид"). Це ViewModel, до якого пов'язується View, а не модель безпосередньо.

Microsoft надав пояснення щодо MVVM Pattern у середовищі Windows тут .

Ось важливий розділ:

У моделі дизайну Model-View-ViewModel додаток складається з трьох загальних компонентів.

• Модель : Це відображає модель даних, яку споживає ваш додаток. Наприклад, у програмі обміну зображеннями цей шар може представляти набір зображень, доступних на пристрої та API, який використовується для читання та запису в бібліотеку зображень.

• Перегляд : Додаток зазвичай складається з декількох сторінок інтерфейсу користувача. Кожна сторінка, показана користувачеві, є переглядом у термінології MVVM. Перегляд - це код XAML, який використовується для визначення та стилювання того, що бачить користувач. Дані з моделі відображаються користувачеві, і завдання ViewModel - це подавати користувальницький інтерфейс цими даними на основі поточного стану програми. Наприклад, у додатку для обміну зображеннями переглядами буде інтерфейс користувача, який показує користувачеві список альбомів на пристрої, зображення в альбомі та, можливо, інший, який показує користувачеві певну картину.

• ViewModel : ViewModel пов'язує модель даних або просто модель з інтерфейсом користувача або переглядами програми. Він містить логіку, з якою можна керувати даними з моделі, і виставляє дані як набір властивостей, до яких може прив'язуватися інтерфейс XAML або представлення даних. Наприклад, у додатку для спільного використання зображень ViewModel відкриє список альбомів, а для кожного альбому - список зображень. Інтерфейс призначений для того, звідки беруться фотографії та як їх отримують. Він просто знає про набір зображень, які піддаються ViewModel, і показує їх користувачеві.

Я подумав, що однією з головних відмінностей є те, що у MVC ваш V читає ваш M безпосередньо та йде через С для маніпулювання даними, тоді як у MVVM ваш VM діє як M-проксі, а також надає вам доступну функціональність V.

Якщо я не повна мотлоху, я здивований, що ніхто не створив гібрид, де ваш VM - це лише проксі-сервер M, а C забезпечує всю функціональність.

MVC є контрольованим середовищем, а MVVM - реактивним середовищем.

У контрольованому середовищі у вас повинно бути менше коду та загального джерела логіки; який завжди повинен жити в межах контролера. Однак; у веб-світі MVC легко ділиться на логіку створення перегляду та динамічну логіку. Креація живе на сервері, а динамічна - на клієнті. Ви багато бачите з ASP.NET MVC у поєднанні з AngularJS, тоді як сервер створить Перегляд і передати в Моделі та надішле його клієнту. Потім клієнт взаємодіє з представленням даних, і в цьому випадку AngularJS переходить до локального контролера. Після подання Моделі або нової Моделі повертається назад до серверного контролера та обробляється. (Таким чином, цикл триває, і існує багато інших перекладів цього поводження під час роботи з сокетами або AJAX тощо, але по всій архітектурі однакова.)

MVVM - це реактивне середовище, яке означає, що ти зазвичай пишеш код (наприклад, тригери), який активується на основі якоїсь події. У XAML, де процвітає MVVM, це все легко робиться за допомогою вбудованої рамки, що зв'язує дані, але, як згадувалося, це буде працювати в будь-якій системі в будь-якій програмі перегляду з будь-якою мовою програмування. Це не специфічно для MS. ViewModel спрацьовує (як правило, подію, змінену властивістю), і View реагує на неї, залежно від будь-яких тригерів, які ви створюєте. Це може бути технічним, але суть полягає в тому, що Вид не має статусу і не має логіки. Він просто змінює стан на основі значень. Крім того, ViewModels є без громадянства з дуже малою логікою, а Моделі - це стан із суттєвою нульовою логікою, оскільки вони повинні підтримувати стан. Я описую це як стан програми (Model), перекладач стану (ViewModel), а потім візуальний стан / взаємодію (View).

У програмі MVC для настільних ПК або клієнта у вас повинна бути модель, а модель повинна використовуватися контролером. На основі моделі контролер буде змінювати представлення даних. Перегляди зазвичай прив’язуються до контролерів з інтерфейсами, щоб контролер міг працювати з різними переглядами. У ASP.NET логіка для MVC трохи відстала на сервері, оскільки Контролер управляє Моделями та передає Моделі обраному виду. Потім вигляд заповнюється даними, заснованими на моделі, і має власну логіку (зазвичай це інший набір MVC, такий як зроблено з AngularJS). Люди будуть сперечатися і плутати це з додатком MVC і намагатимуться робити те, і в цей момент підтримка проекту з часом стане катастрофою. ЗАВЖДИ ставте логіку та управління в одному місці при використанні MVC. НЕ пишіть логіку перегляду в коді позаду View (або в View через JS для Інтернету) для розміщення даних контролера або моделі. Нехай контролер змінить вигляд. ТОЛЬКО логіка, яка повинна жити в представленні, - це все, що потрібно для створення та запуску через інтерфейс, який він використовує. Прикладом цього є подання імені користувача та пароля. Незалежно від того, незалежно від того, на робочому столі чи веб-сторінці (у клієнта), Контролер повинен обробляти процес надсилання кожного разу, коли «Перегляд» виконує дію «Надіслати». Якщо все зроблено правильно, ви завжди можете легко знайти свій веб-сайт або локальний додаток MVC. Незалежно від того, незалежно від того, на робочому столі чи веб-сторінці (у клієнта), Контролер повинен обробляти процес надсилання кожного разу, коли «Перегляд» виконує дію «Надіслати». Якщо все зроблено правильно, ви завжди можете легко знайти свій веб-сайт або локальний додаток MVC. Незалежно від того, незалежно від того, на робочому столі чи веб-сторінці (у клієнта), Контролер повинен обробляти процес надсилання кожного разу, коли «Перегляд» виконує дію «Надіслати». Якщо все зроблено правильно, ви завжди можете легко знайти свій веб-сайт або локальний додаток MVC.

MVVM особисто мій фаворит, оскільки він повністю реагує. Якщо стан зміни моделі, ViewModel прослуховує та перекладає цей стан, і це все !!! Потім View прослуховує ViewModel для зміни стану, і він також оновлюється на основі перекладу з ViewModel. Деякі люди називають це чистим MVVM, але насправді існує лише один, і мені байдуже, як ви це аргументуєте, і це завжди Чистий MVVM, де Погляд абсолютно не містить логіки.

Ось невеликий приклад. Скажімо, ви хочете, щоб у вас було відкрито слайд меню, натиснувши кнопку. У MVC у вас буде дія MenuPress у вашому інтерфейсі. Контролер дізнається, коли ви натиснете кнопку Меню, а потім скаже «Перегляд» слайд у меню, заснований на іншому методі інтерфейсу, такому як «SlideMenuIn». Зворотній шлях з якої причини? У випадку, якщо контролер вирішує, що ви не можете або хочете зробити щось інше замість цього. Контролер повинен бути відповідальним за перегляд, з видом нічого не робити, якщо контролер не скаже цього. ДОКЛАД; у MVVM меню слайдів в анімації має бути вбудованим і загальним, а замість того, щоб казати про те, щоб пересунути його, буде робити це на основі деякого значення. Таким чином, він слухає ViewModel, і коли ViewModel каже, IsMenuActive = true (або проте) анімація для цього відбувається. Тепер, з цим сказаним, я хочу зробити ще один пункт ПОСЛІДНО ЧИСТО і БУДЬ ЛАСКА звернути увагу. IsMenuActive - це, ймовірно, дизайн BAD MVVM або ViewModel. Створюючи ViewModel, ви ніколи не повинні припускати, що у View взагалі відсутні будь-які функції, а просто передати стан перекладеної моделі. Таким чином, якщо ви вирішите змінити свій погляд, щоб видалити меню і просто показати дані / параметри іншим способом, ViewModel не хвилює. То як би ви керували Меню? Коли дані мають сенс, саме так. Отже, один із способів зробити це - надати Меню список параметрів (можливо, масив внутрішніх ViewModels). Якщо у цьому списку є дані, то меню знає, що відкриється через тригер, якщо ні, то воно знає, що ховається через тригер. Ви просто маєте дані для меню або немає у ViewModel. НЕ вирішуйте показувати / приховувати ці дані у ViewModel .. просто перекладіть стан Моделі. Таким чином, Вид є повністю реактивним та загальним і може використовуватися у багатьох різних ситуаціях.

Все це, мабуть, абсолютно не має сенсу, якщо ви вже хоч трохи не знайомі з архітектурою кожного, і ви навчаєтесь, що це може бути дуже заплутано, оскільки ви знайдете інформацію про ALOT OF BAD в мережі.

Отож ... речі, які слід пам’ятати, щоб правильно це зробити. Вирішіть наперед, як розробити свою програму та дотримуйтесь її.

Якщо ви робите MVC, що чудово, тоді переконайтеся, що контролер керований і повністю контролюєте свій погляд. Якщо у вас є великий перегляд, розгляньте можливість додавання до представлення елементів керування, які мають різні контролери. ПЕРЕКЛАДНО НЕ каскадуйте ці контролери на різні контролери. Дуже страшно підтримувати. Знайдіть хвилину та розробіть речі окремо таким чином, щоб вони працювали як окремі компоненти ... І завжди дозвольте Контролеру сказати Моделі здійснити або зберегти зберігання. Ідеальною установкою залежності для MVC є перегляд ← контролер → модель або з ASP.NET (не запускайте мене )... звичайно, єдине, що потрібно знати контролеру в View в цій точці, здебільшого - це посилання на кінцеву точку, щоб знати, куди повернути Модель.

Якщо ви робите MVVM, я благословляю вашу добру душу, але знайдіть час, щоб це зробити ПРАВО! Не використовуйте інтерфейси для одного. Нехай ваш погляд вирішує, як це буде виглядати на основі значень. Пограйте з представленням представлення даних з переглядом. Якщо у вас з'явився вид, який показує вам меню (як у прикладі), хоча ви цього не хотіли, тоді ДОБРО. Ви вважаєте, працює як слід і реагує на основі цінностей, як слід. Просто додайте ще кілька вимог до вашого тригера, щоб переконатися, що цього не відбудеться, коли ViewModel перебуває у певному перекладеному стані, або накажіть ViewModel, щоб очистити цей стан. У вашому ViewModel НЕ видаляйте це внутрішньою логікою, як ніби ви вирішили звідти, чи повинен Перегляд бачити це чи ні. Пам'ятайте, що ви не можете припустити, що в ViewModel є меню чи немає. І, нарешті, Модель повинна просто дозволяти вам змінювати і, швидше за все, стан зберігання. Тут відбувається перевірка і все; наприклад, якщо Модель не може змінити стан, вона просто позначить себе як брудну чи щось подібне. Коли ViewModel зрозуміє це, він переведе те, що є брудним, і View потім зрозуміє це і покаже деяку інформацію через інший тригер. Всі дані у Перегляді можуть бути прив’язані до ViewModel, тому все може бути динамічним, лише Модель і ViewModel абсолютно не мають уявлення про те, як Перегляд буде реагувати на прив'язку. Власне кажучи, Модель також не має уявлення про ViewModel. При встановленні залежностей вони повинні вказувати так і тільки так t модифікувати стан, то він просто позначить себе як брудне чи щось таке. Коли ViewModel зрозуміє це, він переведе те, що є брудним, і View потім зрозуміє це і покаже деяку інформацію через інший тригер. Всі дані у Перегляді можуть бути прив’язані до ViewModel, тому все може бути динамічним, лише Модель і ViewModel абсолютно не мають уявлення про те, як Перегляд буде реагувати на прив'язку. Власне кажучи, Модель також не має уявлення про ViewModel. При встановленні залежностей вони повинні вказувати так і тільки так t модифікувати стан, то він просто позначить себе як брудне чи щось таке. Коли ViewModel зрозуміє це, він переведе те, що є брудним, і View потім зрозуміє це і покаже деяку інформацію через інший тригер. Всі дані у Перегляді можуть бути прив’язані до ViewModel, тому все може бути динамічним, лише Модель і ViewModel абсолютно не мають уявлення про те, як Перегляд буде реагувати на прив'язку. Власне кажучи, Модель також не має уявлення про ViewModel. При встановленні залежностей вони повинні вказувати так і тільки так Всі дані у Перегляді можуть бути прив’язані до ViewModel, тому все може бути динамічним, лише Модель і ViewModel абсолютно не мають уявлення про те, як Перегляд буде реагувати на прив'язку. Власне кажучи, Модель також не має уявлення про ViewModel. При встановленні залежностей вони повинні вказувати так і тільки так Всі дані у Перегляді можуть бути прив’язані до ViewModel, тому все може бути динамічним, лише Модель і ViewModel абсолютно не мають уявлення про те, як Перегляд буде реагувати на прив'язку. Власне кажучи, Модель також не має уявлення про ViewModel. При встановленні залежностей вони повинні вказувати так і тільки такПерегляд → ViewModel → Модель (і бічна примітка тут ... і це, ймовірно, буде також сперечатися, але мені все одно ... НЕ МАЙТЕ МОДЕЛЮ ДО ВИГОТОВЛЕННЯ, якщо ця МОДЕЛЬ є незмінною; інакше оберніть її належний ViewModel. Перегляд не повинен бачити періоду моделі. Я даю щурам зламати те, що ви бачили, або як ви це зробили, це неправильно.)

Ось моя остання порада ... Подивіться на добре розроблений, але дуже простий додаток MVC та зробіть те саме для програми MVVM. Один матиме більше контролю з обмеженою нульовою гнучкістю, а інший не матиме контролю та необмежену гнучкість.

Контрольоване середовище добре для управління всією програмою з набору контролерів або (з одного джерела), в той час як реактивне середовище може бути розбито на окремі сховища, абсолютно не уявляючи, що решта програми робить. Мікроуправління проти безкоштовного управління.

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

Зрештою, ми всі програмісти і з цією анархією живе всередині нас при кодуванні ... Отже, правила будуть порушені, теорії зміняться, і все це в кінцевому підсумку закінчиться миттям свиней ... Але коли працювати над великими проектів та для великих команд, це дійсно допомагає домовитись про схему дизайну та виконати її. Одного разу він зробить невеликі додаткові кроки, зроблені на початку, пізніше, а межі економії.

Проста різниця: (натхненний курсом Якокова Курса AngularJS)

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

1. Моделі: Моделі містять інформацію про дані. Не дзвонить і не використовує Controller і View. Містить бізнес-логіку та способи подання даних. Деякі з цих даних у якійсь формі можуть відображатися у вікні перегляду. Він також може містити логіку для отримання даних з якогось джерела.
2. Контролер: виконує функцію зв'язку між видом і моделлю. Перегляд викликів Контролер та Контролер викликає модель. Це в основному інформує модель та / або вигляд, щоб змінити, як це доречно.
3. Вид: Робота з частиною інтерфейсу користувача. Взаємодіє з користувачем.

MVVM (модель перегляду з виду моделі)

ViewModel :

1. Це подання стану погляду.
2. Він зберігає дані, які відображаються у поданні.
3. Відповідає на перегляд подій, також логіки презентації.
4. Викликає інші функціональні можливості для обробки бізнес-логіки.
5. Ніколи безпосередньо не просить перегляд нічого не відображати.

MVVM - це уточнення (дискусійне) шаблону презентаційної моделі . Я кажу, що це дискусійне питання, адже різниця полягає лише в тому, як WPF надає можливість робити прив'язку даних та обробку команд.

Модель перегляду - "абстрактна" модель для елементів вашого інтерфейсу користувача. Він повинен дозволяти виконувати команди та дії у вашому погляді невізуально (наприклад, для тестування).

Якщо ви працювали з MVC, ви, мабуть, коли-небудь виявились корисними для створення модельних об'єктів, які відображають стан вашого перегляду, наприклад, для показу та приховування деякого діалогового вікна редагування тощо. У цьому випадку ви використовуєте перегляд моделей.

Шаблон MVVM - це просто узагальнення цієї практики для всіх елементів інтерфейсу користувача.

І це не шаблон Microsoft, що додає, що прив'язка даних WPF / Silverlight спеціально добре підходить для роботи з цією схемою. Але ніщо не заважає вам використовувати його, наприклад, з обличчями сервера java.

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

Намагаючись пролити трохи світла на вищезазначене, я створив цей сценарій із участю MVVM, MVP та MVC. Історія починається з того, що користувач натискає кнопку «ЗНАЙТИ» у додатку для пошуку фільмів…:

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

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

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

Перегляд : Гаразд, зачекай на секунду…. [ MVVM | MVP | MVC ]

( Переглянути виклик ViewModel | Презентатор | Контролер ...) [ MVVM | MVP | MVC ]

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

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

Перегляд : Так,… ось воно… “фортепіано” [ MVVM | MVP | MVC ]

—— Це найважливіша різниця між MVVM І MVP | MVC ———

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

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

ViewController : Дякую, я шукаю пошуковий термін на Моделі, але не оновлю вас безпосередньо. Натомість я запускаю події для searchResultsListObservable, якщо є результат. Тож вам краще за цим спостерігати. [ МВВМ ]

(Спостерігаючи за будь-яким тригером у searchResultsListObservable, View вважає, що він повинен показувати користувачеві деяку смугу прогресу, оскільки ViewModel не буде з цим говорити)

———————————————————————————————

ViewModel | Ведучий | Контролер : Ей, модель , чи є у вас відповідність цьому пошуковому терміну ?: "фортепіано" [ MVVM | MVP | MVC ]

Модель : Hey ViewModel | Ведучий | Контролер , дозвольте мені перевірити… [ MVVM | MVP | MVC ]

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

( Невдовзі … )

———— Це точка розходження між MVVM , MVP та MVC ————–

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

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

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

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

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

ViewModel : Будь-який спостерігач на searchResultsListObservable буде сповіщений про те, що існує цей новий список у презентабельному форматі: [“Вчитель фортепіано 2001 ″,“ Piano 1993 ”]. [ MVVM ]

Перегляд : Дуже дякую презентатору [ MVP ]

Перегляд : Дякую « Контролер » [ MVC ] (Тепер Погляд ставить перед собою питання: як я повинен представити користувачеві результати, які я отримую від Моделі ? Чи повинен рік виробництва фільму прийти першим чи останнім…?)

Перегляд : О, є новий тригер у searchResultsListObservable…, добре, є презентабельний список, тепер я маю лише показати його у списку. Я також повинен приховати смужку прогресу тепер, коли отримаю результат. [ МВВМ ]

Якщо вам це цікаво, я написав низку статей тут , порівнюючи MVVM, MVP та MVC, впровадивши додаток для пошуку фільмів для Android.

Введення сильно набраних ViewModels у вигляд за допомогою MVC

1. Контролер відповідає за оновлення ViewModel та введення його у вигляд. (для отримання запитів)
2. ViewModel є контейнером для DataContext і станом перегляду, таким як останній обраний елемент тощо.
3. Модель містить об'єкти БД і дуже близька до Схеми БД, вона робить запити та фільтрацію. (Мені подобаються EF та LINQ для цього)
4. Модель також повинна враховувати сховища та / або прогнозування результатів на сильні типи (EF має чудовий метод ... EF.Database.Select (запит рядків, parms) для прямого доступу ADO для введення запитів та отримання сильних типів. Це адреса EF повільний аргумент.ЕФ НЕ СЛІД !
5. ViewModel отримує дані та робить ділові правила та перевірку
6. Контролер, що повертається назад, буде викликати метод ViewModel Post та чекати результатів.
7. Контролер введе недавно оновлений Viewmodel у Перегляд. Перегляд використовує лише сильний тип прив'язки .
8. Перегляд просто повертає дані та надсилає події назад до контролера. (див. приклади нижче)
9. MVC перехоплює вхідний запит і спрямовує його до належного контролера із сильним типом даних

У цій моделі більше немає контакту рівня HTTP з об’єктами запиту або відповіді, оскільки MVC-апарат MSFT приховує його від нас.

У роз'ясненні пункту 6 вище (за запитом) ...

Припустимо, такий ViewModel:

public class myViewModel{
     public string SelectedValue {get;set;}
public void Post(){
    //due to MVC model binding the SelectedValue string above will be set by MVC model binding on post back.
    //this allows you to do something with it.
    DoSomeThingWith(SelectedValue);
    SelectedValue = "Thanks for update!";
 }
}

Метод контролера повідомлення буде виглядати так (Див. Нижче), зауважте, що примірник mvm автоматично інстанціюється механізмами зв'язування MVC. Вам ніколи не доведеться опускатися до рівня рядка запиту! Це MVC для створення ViewModel для вас на основі рядків запитів!

[HTTPPOST]   
public ActionResult MyPostBackMethod (myViewModel mvm){
         if (ModelState.IsValid)
        {
               // Immediately call the only method needed in VM...
               mvm.Post()
        }
      return View(mvm);
}

Зауважте, що для того, щоб цей вищезазначений метод діяв так, як ви задумали, у вас повинен бути визначений нульовий CTOR, який ініціалізує речі, які не повертаються у публікації. Повідомлення назад також повинно публікувати пари імен / значень пар для тих речей, які змінилися. Якщо відсутні пари імен / значень, двигун зв'язування MVC робить належну річ, яка просто нічого! Якщо це трапиться, ви можете сказати, що "я втрачаю дані про повідомлення" ...

Перевага цієї моделі полягає в тому, що ViewModel виконує всі «захаращені» роботи, поєднуючись з логікою Model / Buisness, контролер - це лише роутер ротації. Це SOC в дії.

MVVM додає модель перегляду в суміш. Це важливо, оскільки це дозволяє використовувати безліч обов'язкових підходів до WPF, не вкладаючи в цю звичайну модель усі ті специфічні елементи інтерфейсу.

Я можу помилятися, але я не впевнений, що MVVM дійсно змушує контролер в суміш. Я вважаю, що ця концепція більше відповідає: http://martinfowler.com/eaaDev/PresentationModel.html . Я думаю, що люди вирішують комбінувати його з MVC, а не те, що він вбудований у зразок.

З того, що я можу сказати, MVVM перетворюється на MV MVC - це означає, що в традиційній схемі MVC V не зв’язується безпосередньо з M. У другій версії MVC існує прямий зв'язок між M і V. MVVM Схоже, приймає всі завдання, пов'язані з комунікацією M і V, і з'єднує його, щоб від'єднати його від C. Насправді, ще існує більший робочий процес програми застосування (або реалізація сценаріїв використання), які не враховуються повністю в MVVM. Це роль контролера. Видаляючи ці аспекти нижчого рівня з контролерів, вони є більш чистими та полегшують модифікацію сценарію використання програми та логіки бізнесу, а також покращують використання контролерів більше.

Мене дивує, що це відповіді на високу оцінку, не згадуючи про походження MVVM. MVVM - популярний термін, що використовується в спільноті Microsoft, і походить від моделі презентації Мартіна Фаулера . Отже, щоб зрозуміти мотив візерунка та відмінності з іншими, перше, що потрібно прочитати в оригінальній статті про викрійку.

Ну, як правило, MVC використовується у веб-розробці, а MVVM є найпопулярнішим у розробці WPF / Silverlight. Однак іноді веб-архітектор може мати поєднання MVC та MVVM.

Наприклад: ви можете використовувати knockout.js, і в цьому випадку у вас буде MVVM на стороні вашого клієнта. І сервер вашого MVC також може змінитися. У складних додатках ніхто не використовує чисту модель. Можливо, має сенс використовувати ViewModel як "модель" MVC, і ваша реальна модель в основному буде частиною цього віртуального комп'ютера. Це дає додатковий шар абстракції.

MVVMC або, можливо, MVC +, здається життєздатним підходом для підприємств, а також швидким розвитком додатків. Хоча приємно відокремлювати інтерфейс користувача від логіки ділових дій та взаємодії, "чистий" MVVM-зразок та більшість доступних прикладів найкраще працюють на єдиних поглядах.

Не впевнений у своїх проектах, але більшість моїх додатків, однак, містять сторінки та кілька переглядів (для багаторазового використання), і таким чином ViewModels дійсно потребують певної взаємодії. Використання сторінки як контролера взагалі переможе мету MVVM, тому не використання підходу "VM-C" для основної логіки може призвести до .. ну .. складних конструкцій у міру дозрівання програми. Навіть у VB-6 більшість із нас, ймовірно, перестали кодувати ділову логіку в події Button і почали "перенаправляти" команди контролеру, правда? Нещодавно я переглядав багато нових фреймворків на цю тему; мій улюблений однозначно - підхід Магеллана (у кодеплексі). Щасливого кодування!

http://en.wikipedia.org/wiki/Model_View_ViewModel#References

Контролер не замінюється ViewModel в MVVM, тому що ViewModel має абсолютно іншу функціональність, ніж контролер. Вам все одно потрібен контролер, тому що без контролера ваша модель, ViewModel та View не обійдуться багато ... У MVVM у вас теж є контролер, ім'я MVVM просто помилкове.

На мій скромний погляд, MVVMC - це правильна назва.

Як ви бачите, ViewModel - це лише доповнення до шаблону MVC. Він переміщує логіку перетворення (наприклад, перетворює об'єкт у рядок) з контролера в ViewModel.

Я зробив середню статтю для цього.

МВВМ

1. Переглянути ➡ Модель ViewModel

   • Представлення має посилання на ViewModel, але не навпаки.
   • ViewModel має посилання на Модель, але не навпаки.
   • Вид не має посилання на Модель і навпаки.

2. Якщо ви використовуєте контролер, він може мати посилання на Views і ViewModels , хоча контролер не завжди необхідний, як показано в SwiftUI .

3. Обв’язання даних : ми створюємо слухачів для ViewModel Properties.

class CustomView: UIView {
  var viewModel = MyViewModel {
    didSet {
      self.color = viewModel.color
    }
  }

  convenience init(viewModel: MyViewModel) {
    self.viewModel = viewModel
  }
}


struct MyViewModel {
   var viewColor: UIColor {
      didSet {
         colorChanged?() // This is where the binding magic happens.
      }
   }

   var colorChanged: ((UIColor) -> Void)?
}


class MyViewController: UIViewController {

   let myViewModel = MyViewModel(viewColor: .green)
   let customView: CustomView!

   override func viewDidLoad() {
      super.viewDidLoad()

      // This is where the binder is assigned.
      myViewModel.colorChanged = { [weak self] color in 
        print("wow the color changed")
      }
      customView = CustomView(viewModel: myViewModel)
      self.view = customView
   }
}

відмінності в налаштуванні

1. Бізнес-логіка проводиться в контролері для MVC і ViewModels для MVVM.
2. Події передаються безпосередньо з представлення на контролер у MVC, тоді як події передаються з виду в ViewModel до контролера (якщо такий є) для MVVM.

Загальні риси

1. І MVVM, і MVC не дозволяють Перегляду надсилати повідомлення безпосередньо Моделі / с.
2. В обох є моделі.
3. Обоє мають погляди.

Переваги МВВМ

1. Оскільки ViewModels дотримуються ділової логіки, вони є меншими конкретними об'єктами, що полегшує їх тестування. З іншого боку, у MVC бізнес-логіка знаходиться у ViewController. Як можна вірити, що тестовий пристрій контролера перегляду є всебічно безпечним без тестування всіх методів та слухачів одночасно? Ви не можете повністю довіряти результатам одиничного тестування.
2. У MVVM, оскільки бізнес-логіка виводиться з контролера в атомні одиниці ViewModel, розмір ViewController зменшується, і це робить код ViewController більш розбірливим.

Переваги MVC

1. Забезпечення ділової логіки в контролері зменшує потребу у розгалуженні, і тому висловлювання швидше запускаються в кеші, що є більш ефективним порівняно з інкапсуляцією бізнес-логіки у ViewModels.
2. Надання ділової логіки в одному місці може прискорити процес розробки простих додатків, де тести не потрібні. Я не знаю, коли тести не потрібні.
3. Надання ділової логіки у ViewController легше продумати нових розробників.

З практичної точки зору, MVC (Model-View-Controller) є зразком. Однак MVC, використовуваний як ASP.net MVC, у поєднанні з Entity Framework (EF) та "електроінструментами" - це дуже потужний, частково автоматизований підхід для передачі баз даних, таблиць та стовпців на веб-сторінку, будь-яку повну Операції CRUD або лише операції R (Вилучення чи зчитування). Принаймні, коли я використовував MVVM, Моделі перегляду взаємодіяли з моделями, які залежали від бізнес-об'єктів, які, в свою чергу, були "зроблені вручну" і після великих зусиль, пощастило отримати моделі настільки ж хороші, як і те, що дає EF " "в коробці". З точки зору практичного програмування, MVC здається хорошим вибором, оскільки він дає одну кількість корисних програм поза коробкою, але є ще потенціал для додавання дзвіночків.

В доповнення до багатьох наданих відповідей, я хотів би додати деяку додаткову перспективу з точки зору Сучасного веб-клієнта - або з точки зору Rich Web Application .

Насправді в наші дні прості веб-сайти та більші веб-додатки зазвичай побудовані з багатьма популярними бібліотеками, такими як Bootstrap. Побудований Стівом Сандерсоном, Knockout забезпечує підтримку моделі MVVM, яка імітує одне з найважливіших способів поведінки в шаблоні: прив'язка даних через модель View. За допомогою невеликого JavaScript можна реалізувати дані та логіку, які потім можуть бути додані до елементів сторінки з простими data-bindатрибутами HTML, подібно до використання багатьох функцій Bootstrap . Ці дві бібліотеки разом пропонують інтерактивний контент; і в поєднанні з маршрутизацією такий підхід може призвести до простого, але потужного підходу до створення програми для єдиної сторінки .

Аналогічно, сучасна система на стороні клієнта, така як Angular, узгоджено відповідає схемі MVC, але також додає Сервіс. Цікаво, що його рекламують як модель-перегляд-що-небудь (MVW). (Дивіться цю публікацію про переповнення стека .)

Крім того, із зростанням прогресивних веб-фреймворків, таких як Angular 2, ми спостерігаємо зміну термінології та, можливо, нового архітектурного шаблону, де Компоненти складаються з представлення чи шаблону та взаємодіють із службою - все це може міститися у Модуль; і серія Модулів складає додаток.

Раніше я думав, що MVC і MVVM - це одне і те ж. Тепер через існування Flux я можу сказати різницю:

У MVC для кожного перегляду у вашій програмі у вас є модель та контролер, тому я б назвав це view, view model, view controller. Шаблон не говорить про те, як один погляд може спілкуватися з іншим. Тому в різних рамках існують різні реалізації для цього. Наприклад, є реалізації, де контролери спілкуються один з одним, тоді як в інших реалізаціях є ще один компонент, який посередництво між ними. Існують навіть реалізації, в яких моделі перегляду спілкуються між собою, що є розривом шаблону MVC, оскільки до моделі перегляду повинен бути доступний лише контролер перегляду.

У MVVM у вас також є модель перегляду для кожного компонента. Шаблон не визначає, як heck view повинен впливати на модель перегляду, тому зазвичай більшість фреймів просто включають функціональність контролера в модель подання. Однак MVVM все-таки говорить вам, що дані вашої моделі перегляду повинні надходити від моделі, яка є цілою моделлю, яка не відома або призначена для конкретного представлення даних.

Щоб продемонструвати різницю, давайте візьмемо шаблон Flux. Шаблон потоку повідомляє, як повинні переглядати різні погляди в додатку. Кожен огляд слухає магазин і виконує дії за допомогою диспетчера. Диспетчер в свою чергу розповідає всім магазинам про щойно зроблену дію, а магазини оновлюються самі. Магазин у Flux відповідає (загальній) моделі в MVVM. це не звично для будь-якого конкретного виду. Тому зазвичай, коли люди використовують React і Flux, кожен компонент React реально реалізує схему MVVM. Коли відбувається дія, модель перегляду викликає диспетчера, і нарешті вона оновлюється відповідно до змін у магазині, який є моделлю. Ви не можете сказати, що кожен компонент реалізує MVC, оскільки в MVC лише контролер може оновлювати модель перегляду.

mvc стоїть на сервері, а mvvm - на стороні клієнта (браузера) у веб-розробці.

більшу частину часу JavaScript використовується для mvvm у браузері. існує багато технологій на стороні сервера для mvc.

Коротше кажучи - у MVC Controler відомо (контролює) перегляд, тоді як у MVVM ViewModel не знає, хто його споживає. ViewModel виявляє свої спостережувані властивості та дії тому, хто може бути зацікавлений у використанні ним. Цей факт полегшує тестування, оскільки в ViewModel немає посилання на інтерфейс користувача.

Модель – перегляд – контролер (зазвичай відомий як MVC ) - це модель дизайну програмного забезпечення, яка зазвичай використовується для розробки інтерфейсів користувача, які поділяють відповідну логіку програми на три взаємопов'язані елементи. Це робиться для відокремлення внутрішніх уявлень інформації від способів подання та прийняття інформації користувачем. Дотримуючись архітектурного зразка MVC, ці основні компоненти дозволяють використовувати повторне використання коду та паралельну розробку.

Традиційно використовується для графічних інтерфейсів користувачів настільних ПК (GUI), ця модель стала популярною для розробки веб-додатків. Популярні мови програмування, такі як JavaScript, Python, Ruby, PHP, Java та C #, мають рамки MVC, які використовуються при розробці веб-додатків прямо з вікна.

Модель

Центральний компонент візерунка. Це динамічна структура даних програми, незалежна від інтерфейсу користувача. Він безпосередньо керує даними, логікою та правилами програми.

Вид

Будь-яке представлення інформації, наприклад діаграми, діаграми або таблиці. Можливі кілька переглядів однієї й тієї самої інформації, такі як гістограма для менеджменту та таблична таблиця для бухгалтерів.

Контролер

Приймає введення та перетворює його в команди для моделі чи перегляду.

На додаток до поділу програми на ці компоненти, модель модель-перегляд – контролер визначає взаємодію між ними.

Модель відповідає за управління даними програми. Він отримує введення користувача від контролера.

Перегляд означає презентацію моделі у певному форматі.

Контролер відповідає на введення користувача та здійснює взаємодію з об'єктами моделі даних. Контролер отримує вхід, додатково перевіряє його, а потім передає вхід моделі.

Модель – Вид – ViewModel (MVVM) - це програмний архітектурний зразок.

MVVM полегшує розмежування розвитку графічного інтерфейсу користувача - будь то за допомогою мови розмітки або GUI-коду - від розробки бізнес-логіки або логіки бек-енду (модель даних). Модель перегляду MVVM є перетворювачем значень, тобто модель подання відповідає за викриття (перетворення) об'єктів даних з моделі таким чином, що об'єктами легко керувати та представляти. У цьому відношенні модель перегляду є більш моделлю, ніж видом, і обробляє більшість, якщо не всю логіку відображення перегляду. Модель перегляду може реалізувати модель посередника, організуючи доступ до зворотної логіки навколо набору випадків використання, підтримуваних видом.

MVVM - це варіант дизайну моделі дизайну презентації Мартіна Фаулера. MVVM резюмує стан та поведінку подання однаково, але презентаційна модель абстрагує вид (створює модель подання) таким чином, що не залежить від конкретної платформи інтерфейсу користувача.

MVVM був винайдений архітекторами Microsoft Кен Купер і Тедом Петерсом спеціально для спрощення програмованого керування подіями користувальницьких інтерфейсів. Ця модель була включена до Фонду презентацій Windows (WPF) (графічна система .NET Microsoft) та Silverlight (похідна програма для Інтернет-додатків WPF). Джон Госсман, один із архітекторів Microsoft WPF та Silverlight, анонсував MVVM у своєму блозі у 2005 році.

Model – View – ViewModel також називається сполучною моделлю-view – binder, особливо в реалізаціях, що не включають платформу .NET. ZK (фреймворк веб-додатків, написаний на Java) та KnockoutJS (бібліотека JavaScript) використовують в'яжучу модель-перегляд – перегляд.