Что входит в «Контроллер» в «MVC»?

Question

Мне кажется, я понимаю основные концепции MVC - модель содержит данные и поведение приложения, представление отвечает за его отображение пользователю, а контроллер обрабатывает ввод данных пользователем. В чем я не уверен, так это , что идет в контроллере.

Допустим, например, у меня довольно простое приложение (я специально думаю о Java, но я полагаю, что те же принципы применимы и в других местах). Я организую свой код в 3 пакета, которые называются app.model, app.view и app.controller.

В пакете app.model у меня есть несколько классов, которые отражают реальное поведение приложения. Они extends Observable и используют setChanged() и notifyObservers(), чтобы активировать представления для обновления при необходимости.

В пакете app.view есть класс (или несколько классов для разных типов отображения), который использует компоненты javax.swing для обработки отображения. Некоторые из этих компонентов должны быть возвращены в модель. Если я правильно понимаю, представление не должно иметь ничего общего с обратной связью - с этим должен справиться Контроллер.

Так что я на самом деле вставляю в контроллер? Поместить ли public void actionPerformed(ActionEvent e) в представление просто вызовом метода в контроллере? Если да, следует ли выполнять какие-либо проверки и т. Д. В контроллере? Если да, то как я могу отправить сообщения об ошибках обратно в View - это должно пройти через Модель снова, или Контроллер должен просто отправить его обратно в View?

Если проверка выполняется в представлении, что я могу добавить в контроллер?

Извините за длинный вопрос, я просто хотел документировать свое понимание процесса, и, надеюсь, кто-то может прояснить этот вопрос для меня!

Answer 1

также обратите внимание, что каждый виджет Swing может рассматриваться как содержащий три компонента MVC: каждый имеет Model (т.е. ButtonModel), View (BasicButtonUI) и Control (сам JButton).

Answer 2

Мы делаем это таким образом, используя контроллеры в основном для обработки и реагирования на пользовательский ввод / действия (и _Logic для всего остального, кроме представления, данных и очевидных вещей _Model):

(1) (ответ, реакция - что веб-приложение «делает» в ответ на пользователя) Blog_Controller

-> main ()

-> handleSubmit_AddNewCustomer ()

-> verifyUser_HasProperAuth ()

(2) («бизнес» логика, что и как «думает» веб-приложение) Blog_Logic

-> sanityCheck_AddNewCustomer ()

-> handleUsernameChange ()

-> sendEmail_NotifyRequestedUpdate ()

(3) (представления, порталы, как «веб-приложение выглядит») Blog_View

-> genWelcome ()

-> genForm_AddNewBlogEntry ()

-> genPage_DataEntryForm ()

(4) (только объект данных, полученный в _ construct () каждого класса Blog *, используемый для хранения всего webapp / inmemoryданные вместе как один объект) Blog_Meta

(5) (базовый уровень данных, чтение / запись в БД) Blog_Model

-> saveDataToMemcache ()

-> saveDataToMongo ()

-> saveDataToSql ()

-> loadData ()

Иногда мы получаемнемного запутано в том, куда поместить метод, в C или L. Но Модель очень прочная, кристально чистая, и, поскольку все данные в памяти находятся в _Meta, там тоже нет ничего сложного.Между прочим, нашим самым большим шагом вперед было принятие использования _Meta, поскольку это очистило все грубое от различных объектов _C, _L и _Model, сделало его умственно простым для управления, плюс одним махом оно дало нам то, что происходит.называется «Внедрение зависимостей», или способ обойти всю среду вместе со всеми данными (преимуществом является простое создание «тестовой» среды).

Answer 3

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