Model-View-Controller: Чи взаємодіє користувач із View або Controller? [зачинено]


14

Нещодавно я дізнався про модель дизайну MVC. Я навчаюсь із книги «Перший шаблон дизайну керівника».

Відповідно до цієї книги (якщо я правильно розумію):

Модель є більшістю логіки та даних програми.

Перегляд - це в основному GUI, який візуально представляє модель для користувача.

Контролер несе відповідальність за "посередництво" та виступає як "посередник" між Поглядом та Моделлю. Перегляд повідомляє Контролеру про те, що користувач здійснив дію, і Контролер перекладає його на виклики методу на Моделі.

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

Який із них правдивий чи більш поширений? Чи взаємодіє користувач із контролером безпосередньо чи з представленням безпосередньо? Чи прийнятні обидва підходи? Що є більш поширеним?


4
Це запитання не відповідає суттєво тому, як ви його написали. Наведіть нам приклад одного з місць в Інтернеті, яке суперечить книзі, і ми спробуємо пояснити це. Будьте конкретні зі своїм прикладом.
Роберт Харві

1
2 відповіді, обидва сприйняті, один говорить "взаємодію з поданням", інший каже "взаємодію з контролером" .... змушує мене думати, що MVC не дуже хороша архітектура, якщо її це плутає на такому фундаментальному рівні!
gbjbaanb


Ви натискаєте на елементи керування програми чи запити до бази даних? Взаємодія відбувається безпосередньо з користувальницьким інтерфейсом, який сам по собі є переглядом. Перегляд зазвичай викликає запити до сервера (у випадку веб-додатків) або викликає зареєстровані на них гачки (у разі клієнтських додатків). Крім того, що весь MVC - це просто лайно.
luke1985

@spectre Не корисно звільняти MVC, не надаючи пояснення та, в ідеалі, альтернативи. Інакше звільнення нічого не сприяє, і ви повинні були просто залишитися без вашого коментаря. Крім того, навіть з цим це все одно буде поза темою.
підкреслюй_d

Відповіді:


18

У взаємодіє користувач з видом , але View повинен повідомити дії до контролера . Контролер може оновити модель , але це не потрібно при кожному / які - або зміни.

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

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

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

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


ОНОВЛЕННЯ

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

MVC - це спроба побудувати модель дизайну розділення концернів для розробки програмного забезпечення. Він в основному був реалізований у веб-додатках (наскільки мені відомо).

View обробляє всі взаємодії з користувачем. Якщо ваш користувач натискає кнопку, представлення перегляду визначає, чи це клік - це взаємодія користувальницького інтерфейсу чи щось, що не викликає занепокоєння (взаємодія контролера). Якщо кнопка робить щось на зразок копіювання значень з одного поля в інше, Ваша реалізація визначить, чи це занепокоєння View або ступінь Controller. Ця розмитість, швидше за все, ви матимете лише тоді, коли будете мати справу з додатком на одній сторінці (SPA).

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

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


У Вікіпедії є стаття про MVC .

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

З огляду Microsoft MVC .

  • Моделі. Об'єкти моделі - це частини програми, які реалізують логіку домену даних програми. Часто об'єкти моделей отримують і зберігають стан моделі в базі даних. Наприклад, об'єкт Product може отримати інформацію з бази даних, оперувати нею і потім записати оновлену інформацію в таблицю Products в базу даних SQL Server.

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

  • Перегляди. Перегляди - це компоненти, які відображають користувальницький інтерфейс програми (UI). Зазвичай цей інтерфейс створюється з даних моделі. Прикладом може бути перегляд таблиці таблиці продуктів, яка відображає текстові поля, випадаючі списки та прапорці відповідно до поточного стану об’єкта Продукту.

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


Що робити, якщо у вас немає графічного інтерфейсу для всіх дій? Що робити, якщо у вас реалізовано лише API для деяких конкретних частин? Чи означає це, що користувач іноді взаємодіє з представленням даних, а іноді безпосередньо з контролером?
Махді

1
З моєї точки зору, ні. API займає місце перегляду.
Адам Цукерман

але API може бути простим url-routes, розміщеним у Controller. Я маю на увазі відсутність Перегляду взагалі ...
Махді

1
@AdamZuckerman Дякую за відповідь. У наступному коментарі я опишу, як я думаю, що працює звичайна реалізація MVC, будь ласка, підтвердьте, чи вона правильна чи ні. Спасибі
Авів Кон

2
@Mahdi API, за визначенням, існує як інтерфейс програмування , а не інтерфейс користувача . Програми взаємодіють з API, користувачі взаємодіють із представленням даних.
Ерік Кінг

4

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

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

Також не всі програми - навіть MVC-додатки, мають графічний інтерфейс. Ви можете взаємодіяти з Контролером через API - просто простий, url-routesнаприклад, розміщений у самому Контролері .

Контролер повинен бути місцем , яке отримує і Рукоятки запитів користувачів. Тож якщо ви якимось чином отримуєте доступ до моделі безпосередньо з View - не важливо, як, то це вже не MVC .


2
+1 Це правильно. Такі речі, як меню та панелі інструментів, є частиною графічного інтерфейсу, але не є частиною перегляду, і переходять безпосередньо до контролера. Клавіші також.
david.pfx

1
Причини погляду існують як абстракція, тому ми можемо легко їх замінити, коли це необхідно. Контролер для програми на різних платформах може бути однаковим, але представлення повинні розпізнавати жести користувачів по-різному і переводити їх в операції контролера. Тому я не згоден з тим, що користувачі взаємодіють безпосередньо з контролерами.
Фурманатор

1
@Mahdi Я б сказав, що в такому випадку взагалі немає взаємодії з користувачем, це перегляд програмного спілкування з контролером. Єдині взаємодії, які ініціюються користувачем, - це перегляд.
Ерік Кінг

1
@ david.pfx Натискання клавіш не може переходити безпосередньо з вікна браузера до контролера.
Адам Цукерман

1
@Izkata "Перегляд - це частина коду, на який надсилаються запити" - Вибачте, але це найгірше, що я чув тут. Як це можливо? Чи можете ви створити резервну копію, надавши посилання у статті чи книзі?
Махді

1

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

У музичному додатку на iPhone особливістю високого рівня є відтворення списку відтворення. "Відтворити список відтворення" - це функція контролера програми.

Існує більше ніж один спосіб активувати цю функцію. Я можу натиснути на список відтворення всередині програми або ж попросити Siri (голосовий інтерфейс) виконати ту саму функцію. Це два різні жести , які розпізнаються різними поглядами.

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

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.