Чи мають вигляд та модель спілкуватися чи ні?

Згідно сторінки вікіпедії для архітектури MVC , модель може вільно повідомляти про тип, а також безкоштовно запитувати модель про її поточний стан. Однак, згідно з курсом Пола Гегарті на iOS 5 в Стенфорді, лекція 1, стор. 18, вся взаємодія повинна проходити через контролер, з Model і View, які ніколи не повинні знати один одного. Мені незрозуміло, чи слід висловлювання Гегарті розраховувати як спрощення курсу, але я спокушаюся сказати, що він має намір дизайн як такий.

Як ви пояснюєте ці дві протилежні точки зору?

Це спірна тема в MVC / MVVM. Одні говорять, що це нормально для View, щоб отримати доступ до Моделей безпосередньо, інші кажуть, що слід загортати Моделі у ViewModels, щоб абстрагувати їх від подання. Я особисто не прихильник жодного підходу.

Однією з головних цілей MVC / MVVM є роз'єднання інтерфейсу користувача, бізнес-логіка та дані. Отже, маючи на увазі цю концепцію, дозвол Перегляду безпосередньо отримувати доступ до Моделей створює залежність, яку ви, можливо, не хочете мати. З іншого боку, загортання Моделей у ViewModels часто є стомлюючим і не дуже корисним, оскільки ViewModels, як правило, виступають просто як прохід до Моделей.

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

В Інтернеті всі називають свій роз'єднаний MVC.

Деякі технології, такі як C #, використовують MVVM, оскільки немає зв'язку між Переглядом та будь-якими іншими, все проходить через сервіс-локатор, прив'язуючи змінні.

Щодо чистого MVC, Перегляд розмовляє безпосередньо з Моделлю і навпаки. Контролер є лише тоді, коли виникають будь-які зміни.

А потім є той, який називається PAC (Presentation Abstraction Control). У цій архітектурі Вид і модель не розмовляють один з одним. Контролер - єдиний, кому дозволяється робити що-небудь з видом або моделлю. Люди часто плутають це з MVC.

Тут ви побачите спосіб кращого пояснення: http://www.garfieldtech.com/blog/mvc-vs-pac

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

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

У MVC Пол Гегарті помиляється. Контролер стосується подій користувача, а не моделювання для перегляду. У класичних MVC подання (и) спостерігають (-ла) модель (шаблон спостерігача).

Якщо між посередниками проводиться посередництво, модель слід називати MVP , і насправді більшість того, що сьогодні представлено як MVC, насправді наближається до MVP.

Потім є MVVM, який є чимось подібним до обох, і все ж трохи іншим, і існував давно ... найкраще бачити це як два MVC / MVP, пов'язані разом через об'єкт viewmodel - "клієнт" MVC має viewmodel як його модель, і "серверний" MVC має перегляд моделей.

Оскільки ви запитуєте про матеріал, зокрема, на цих лекціях про Стенфорда, варто розглянути дві речі про позицію Гегарті:

1. Як ви вже згадували, він викладає курс інформатики рівня l00. У його лекціях є багато місць, де він спрощує, оглядає деталі або каже "просто зроби це так", як це, мабуть, треба при навчанні основ, тобто ви повинні опанувати правила, перш ніж ви зможете їх порушити.
2. Мій досвід роботи з SDK для iOS полягає в тому, що там, де він не застосовує суворого поділу між View і Model, він сильно орієнтований на цю модель. Зокрема, під час написання додатків для iOS дотримання розділення перегляду моделей допомагає написати код, який відповідає очікуванням рамки. Я б вагався, щоб узагальнити заяви Хегарті щодо розвитку на інших платформах або взагалі.

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

У невеликих додатках (як правило, на робочому столі), де я хотів би уникати "фіктивних" класів ViewModel і робити все просто, я також використовую інтерфейс IModel (див. Відповідь вище) і дбаю, щоб модель не мала уявлення про перегляд (використовуйте підписники як у класичному MVC).

Також у цьому випадку контролер виявляється досить поєднаним з представленням, і для простоти я не завжди чітко їх розділяю.

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

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

Ви знайдете людей з різними переконаннями. Архітектури - це концепції, які допомагають розробляти кращі рішення.

Окрім комунікацій із перегляду моделі, у MVC існує ще одне протиріччя щодо логіки бізнесу. Багато людей вважають, що вся бізнес-логіка повинна бути однією моделлю (див. Це питання ТАК ), з іншого боку, посилання, яким поділився Флоріан (у своїй відповіді), говорить, що ділова логіка повинна бути на контролері.

Крім цього існує можливість поділу ділової логіки на логіку Application (поставити її на контролер) та логін домену (поставити його на модель).

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

Я використовую DTO для зв'язку з переглядом моделі.

Наприклад:

• Користувач заповнює форму оновлення (Перегляд)
• Користувач надсилає форму
• Контролер пов'язує дані форми з UserUpdateDTO
  • DTO та UserModel - POJO, але DTO не має ідентифікатора та імені користувача, оскільки ми не можемо оновити ім'я користувача.
  • Ще одна відмінність полягає в тому, що клас Model має відносини та асоціації, але DTO зберігає лише дані, і ми можемо додати до нього валідатори JSR 303
• Контролери говорять, що це службовий рівень для економії
• Сервісний рівень каже, що рівень DAO зберігає дані

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

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

Оскільки багато з них пропонують питання про те, чому і як перегляд та модель повинні вільно взаємодіяти в різних контекстах, але головна причина в iOS для створення Controller є посередником між ними - уникати залежностей Model & View у вашій кодовій базі та дозволяє нам повторно використовувати або модель, або перегляд відповідно до вимог, що розвиваються iOS.

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

Хоча я погоджуюся, що MVC в iOS виробляє гігантські ViewControllers з великою кількістю різних логік в ньому та обробляє всілякі речі, крім того, для чого він призначений. Тому краще скористатися MVVM або Presentation Controls, щоб зробити базу коду більш гнучкою, простою читати та підтримувати за допомогою менших ViewControllers.

Це може допомогти тим, хто шукає менші ViewControllers в iOS:

http://blog.xebia.com/simplification-of-ios-view-controllers-mvvm-or-presentation-controls/