Подтвердить что ты не робот

Как работает система MVC?

Я пытаюсь изучить шаблон MVC, но в каждом месте говорят что-то другое. Итак, теперь я не знаю, что такое истинный MVC.

Итак, я предполагаю, что это самый чистый MVC:

  • Модель - это только данные и уведомляет об изменениях данных.
  • Просмотр читает сообщения Модель, чтобы обновить представление.
  • Контроллер читает пользовательский ввод Вид и изменяет модель согласно.

Реализация

  • Модель не знает никого.
  • Просмотр знает Модель.
  • Контроллер знает как Вид, так и Модель.

псевдокод:

/* Model */
class Color{ 
  color = blue;
  setColor(color);
  notifyUpdate();
}
/* View */
class ColorPicker(model){
  model.register(update);
  update(){
    this.colorToExhibit = model.color;
  }
}
/* Controller */
class Colorize(view, model){
  view.register(update);
  update(color){
    model.setColor(color);
  }
}

Некоторые вопросы:

  • Правильно ли это?
  • Я не понимаю, почему Вид не может напрямую изменить Модель, но через Контроллер.
  • Предположим, что анимация выполняется после действия. Кто должен обрабатывать эту анимацию: модель, представление или контроллер? Также: логика анимации является частью модели, представления или контроллера? Подробнее: предположим покерную игру. После того, как пользователь выберет действие (например, "Поднять" ), система должна воспроизвести анимацию (скажем, чипы, идущие от плеера до стола). Как я могу увидеть этот покерный пример (с анимацией) как MVC? Можете ли вы объяснить и дать псевдокод об этом?

Спасибо.

4b9b3361

Ответ 1

  • Модель - это просто данные и уведомления об изменениях данных.
  • Просмотр читает сообщения Модели для обновления представления.
  • Контроллер считывает пользовательский ввод из представления и изменяет модель согласно.

Модель - это больше, чем просто данные. Модель также является бизнес-логикой. Он содержит весь интеллект системы или, по крайней мере, абстракцию за кадром (например, вызовы базы данных или другие вызовы служб). Рассмотрите высказывание: "Держите ваши модели тяжелыми и ваши контроллеры светят".

  • Модель не знает никого.
  • Просмотр знает модель.
  • Контроллер знает как View, так и Model.

Модель никого не знает, что она правильная. Модель должна быть переносимой между приложениями и никоим образом не должна зависеть от требований пользовательского интерфейса. (View и Controller - это проблемы пользовательского интерфейса в этом случае.)

The View знает модель, также верно. Вид в основном "привязывается" к модели. Он представляет все элементы пользовательского интерфейса и помещает данные модели в элементы пользовательского интерфейса соответственно.

Тип контроллера "знает представление". Он знает, к какому представлению следует управлять, но он ничего не знает об этом представлении. Он также не знает, какой вид, из которого ранее выполнялся контроль. Контроллер отвечает на события. Событие приходит из пользовательского интерфейса, неся с ним какую-то информацию о состоянии (возможно, ViewModel), направляет логический контроль через Модели (где происходит бизнес-логика) и отвечает моделью (или ViewModel, если форма данных, специфичных для конкретного вида, отличается от моделей) и View.

Я не понимаю, почему представление не может напрямую изменить модель, но через контроллер.

View может манипулировать моделью в контексте взаимодействия с пользователем, но не должен ожидать, что эти изменения будут сохраняться в любом случае. Вид следует рассматривать как "клиентскую сторону" и ничего не знает "на стороне сервера". (Даже если вы говорите о родном приложении, а не о веб-приложении.) Сохранение любых изменений считается пользовательским интерфейсом "действие" или "событие" и отправляется на контроллер, чтобы это произошло.

Предположим, что анимация выполняется после действия. Кто должен обрабатывать эту анимацию: модель, представление или контроллер? Кроме того: логика анимации является частью модели, представления или контроллера?

Анимация звучит как полностью основанная на пользовательском интерфейсе операция. Это будет в представлении. Происходит ли больше, чем просто анимация пользовательского интерфейса? Изменяет ли анимация что-либо в фоновом режиме? Например, если у меня есть веб-приложение, и, когда загружается страница, я хочу затухать некоторые данные (анимацию)... полностью в представлении. Данные будут доставлены в представление как любые другие данные, и анимация будет полностью выполнена в пользовательском интерфейсе (View). Он не делает ничего с точки зрения Модели или Контролера.

Предположим, игра в покер. После того, как пользователь выберет действие (например, "Поднять" ), система должна воспроизвести анимацию (скажем, чипы, идущие от плеера до стола). Как я могу увидеть этот покерный пример (с анимацией) как MVC? Можете ли вы объяснить и дать псевдокод об этом?

Действие ( "Поднять" ) является событием контроллера. Пользовательский интерфейс должен связаться с контроллером для выполнения "рейза". Таким образом, у контроллера может быть такой метод:

View Raise(GameState state)
{
    // Interact with the Models to update the known state of the game.
    // The Models would perform the actual Poker game logic.
    // Respond with a View bound to updated Models.
}

Как только контроллер реагирует на пользовательский интерфейс с новым представлением, этот вид будет содержать любые анимации для отображения пользователю. (В конце концов, вы не хотите выполнять анимацию, если действие не было успешным, правильно? Когда контроллер отвечает на пользовательский интерфейс с новым представлением, показывающим успешное действие, тогда будет воспроизводиться анимация. Вместо этого он может отвечать на пользовательский интерфейс с представлением, указывающим на ошибку, и в этом случае этот вид будет показывать что-то еще.)

Ответ 2

Я пойду с простой банковской аналогией.

  • Теллеры - это представления.
  • Бегуны - это контроллеры.
  • Банкиры - это модели.

Банкиры - умные, они знают всю бизнес-логику и выполняют все сложные вычисления.

Бегуны используются для переноса денег (данных) от банкиров на тестеры.

Теллер представляет деньги Клиенту.

Простое представление:

Model

public class BankAccount
{
     public int ID;
     public int Balance;

     public BankAccount(int id)
     {
         ID = id;
         Balance = DetermineAmount();
     }

     public int DetermineAmount()
     {
         // Gather transaction info, debits, credits and return a
         // sum of the amount left in the account depending on the
         // id provided.
     }
}

контроллер

    public class BankAccountController
    {

         public ViewResult Index(int id)
         {
             BankAccount account = new BankAccount(id);
             return View(account);
         }

    }

Просмотр

<ul id="account-info">
   <li>Account ID: `@Model.ID`</li>    
   <li>Balance: `@Model.Balance`</li>
</ul>

Ответ 3

Если вы заинтересованы в историческом истинном MVC, начните с Trygve Reenskaug. Он создал (заметил?, каталогизировал??) его в конце 1970-х годов. Для начала прочитайте "Models-Views-Controllers" от 1979 года. Он определяет терминологию. Внимательно запомните его заголовок - все три роли являются множественными. Это первое, что большинство людей, похоже, ошибаются.

Наилучшее описание оригинального использования MVC, которое я нашел, - это презентация 2004 года, озаглавленная "Inside Smalltalk MVC". Я предполагаю, что канонические статьи, описывающие финальную версию Smalltalk 80 MVC, - это "Краснер и Ампер"; Папа "Кулинарная книга по использованию парадигмы пользовательского интерфейса Model-View-Controller в Smalltalk-80" и  Стив Бербек "Программирование приложений в Smalltalk-80: как использовать Model-View-Controller (MVC)". Обе статьи достойны прочтения.

Если у вас есть время, чтобы убить и не возражаете слушать Роберта Мартина, он выступил с хорошим основным докладом на Ruby Midwest 2011, который коснулся MVC. Это чуть более часа, но довольно занимательно и поучительно. Я склонен придерживаться его мнения, что большинство реализаций неправильно интерпретируют MVC. Я провел немного времени, оглядываясь по сторонам, и, наконец, нашел схему, на которую я могу ссылаться и которая описывает MVC. Тот, который мне нравится, пришел от папы и Краснера.

MVC
(источник: as3dp.com)

С моей точки зрения, ключевыми являются следующие:

  • экземпляр модели отвечает за уведомление заинтересованных объектов об изменениях. Обратите внимание, что это могут быть любые экземпляры объектов. На диаграмме показаны и представления, и контроллеры, получающие обновления здесь.
  • Представления отвечают за запрос текущего состояния и отображение результатов. Обычно они также выполняют фильтрацию или преобразование данных.
  • контроллеры несут ответственность за принятие пользовательского ввода и пересылку сообщений вида вместе с видом.
    • Просмотр сообщений - распространенная тема в MVC. Важно, чтобы они не зависели от мира пользовательского интерфейса - это не щелчки мышью, а что-то другое, а не язык событий. Это подводит нас к следующему пункту.
  • Представление никак не зависит от контроллера. Контроллер отвечает за организацию и создание представлений и обеспечение интерфейса между остальным миром и представлением.
  • В идеальном мире представление отвечает за то, чтобы представление модели было видимым. Вот как это работает, когда MVC был применен к настольным приложениям.

Реальность такова, что MVC был изменен и переписан для веб-мира. Это больше не MVC или, может быть, MVC был просто переопределен. Вот почему вы видите так много разных мнений и представлений о MVC. Если вы хотите писать приложения в стиле рабочего стола, тогда посмотрите на материал от Krasner & Папа. Если вы изучаете, как MVC применяется в сети, то я рекомендую дядю Бобу ключевую ноту в качестве альтернативы, которая лучше подходит для веб-приложений - то, что он назвал Interactor, Entity, Boundary Architecture из-за отсутствия лучшего названия. Покопайтесь в поисках вещей, связанных с его разговорами о "Потерянных годах архитектуры".