Откуда поступает пользовательский ввод в архитектуре MVC? - PullRequest
4 голосов
/ 29 июля 2009

Я хотел бы знать, откуда контроллер получает пользовательский ввод (для подачи модели). Поскольку носители ввода тесно связаны с пользователем, разве представление не должно знать о конкретном способе получения данных пользователя? Но как тогда отделить контроллер от вида? Можно ли сделать оба полностью независимыми друг от друга, как предполагают их цели?

Пример: Когда у меня есть приложение, которое использует библиотеку curses для представления, это означает, что оно доступно только через терминал. Использование методов curses для чтения пользовательских данных в контроллере нарушит инкапсуляцию, но вызов методов в представлении не будет иметь ничего общего с отображением модели.

Ответы [ 5 ]

3 голосов
/ 29 июля 2009

В MVC контроллер получает свой пользовательский ввод от просмотра.

1 голос
/ 29 июля 2009

Я не думаю, что представление действительно имеет много общего с вводом данных на самом деле. Я считаю, что MVC гораздо проще визуализировать, если вы видите, что пользователь общается с контроллером напрямую. Контроллер получает данные от пользователя и отправляет их обратно. Во многих системах механизм представления имеет ограниченный способ обновления (т. Е. Текстовые вводы отображают то, что набрано перед отправкой в ​​контроллер). Но для любой архитектуры типов MVC вы можете заменить любое представление любым другим представлением, если они оба способны обрабатывать одни и те же данные.

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

1 голос
/ 29 июля 2009

Подумайте о том, чтобы View и Controller взаимодействовали через Observer pattern . Контроллер регистрирует себя в качестве наблюдателя в представлении. Когда пользователь вводит данные в представление и нажимает клавишу Enter, тогда представление интерпретирует данные и уведомляет своих наблюдателей о наличии доступных данных. Контроллер может затем получить данные из представления открытым способом.

0 голосов
/ 29 июля 2009

Ну

Я постараюсь быть более конкретным для вас. Давать расплывчатые / абстрактные ответы на вопросы о госзакупках, которые вы видите, не осваиваете предмет, не помогает.

MVC -> Model View Controler

Существует множество реализаций MVC, я не знаю вашего случая, но я дам вам один.

Наиболее распространенная реализация MVC действует следующим образом.

просмотр <-> Контроллер <-> модель

В веб-сценарии ..

Представлением будут ваши HTML-страницы, а ввод данных будет осуществляться в форме.

<form action=/home/createuser method=post>
...code goes here...
</form>

Home будет вашим контроллером (класс с именем home) и создаст пользовательский метод в home.

public class Home extends Controller {

   public void createUser(Userform f){
      ...create user...
   }
}

Эта форма будет передавать данные в метод в качестве параметров. Createuser обработает их, чтобы поговорить с моделью, а затем сохранить данные, если это так.

0 голосов
/ 29 июля 2009

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

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...