Не уверены в использовании шаблона проектирования MVC

Question

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

loginpanelView: просто графический интерфейс с текстовыми полями, метками, кнопками и т. Д.

loginpanelController: - реализуйте список действий для кнопки запуска здесь и получите ссылкук методу checkLogin - реализовать здесь actionlistener для добавления пользовательской кнопки и иметь ссылку на метод, который переключает панели

loginModel: - определяет фактический метод, который проверяет логин

switchpanelModel: - определяетметод, который создает систему раскладки карт и переключает панели

Насколько я понимаю, контроллер просто дает очень общие ссылки на то, что должно быть сделано, то есть на то, что пользователь хочет сделать, тогда модель определяет точный методкак справиться с этим?Кто-нибудь возражает против проверки / исправления моего понимания, пожалуйста?Я много читал об этом шаблоне проектирования, но, к сожалению, я все еще не чувствую, что у меня есть четкое понимание этого.Любая помощь будет высоко ценится!

ps Извините!Я забыл указать, что я программирую на Java

Answer 1

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

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

Answer 2

Хорошее место для начала - здесь . Это особый случай MVC, называемый пассивным представлением. Первая важная идея заключается в том, что представление и модель вообще не взаимодействуют друг с другом. Представление только сообщает контроллеру о событиях, и контроллер управляет как представлением, так и моделью. Контроллер может даже создавать новые контроллеры и представления (например, для сложных модальных диалогов). И наконец, модель ни с кем не общается!

Итак, у вас есть правильная идея: ваш loginpanelController прослушивает события кнопок из loginpanelView, а затем вызывает правильные методы в модели, чтобы установить данные и проверить их.

Я думаю, что единственное место, с которым у вас могут возникнуть проблемы, это switchpanelModel. Я не думаю, что вам это нужно. Если ваш loginpanelView - это вид с картами в нем, то ваш loginpanelController должен быть тем, который переключает карты.

Я думаю, что модели должны быть ограничены методами, работающими с собственными данными, но нигде не должны ссылаться на какой-либо элемент GUI. Модели не управляют программой; контроллеры делают.

Answer 3

Мне кажется, что LoginModel и SwitchPaneModel вообще не являются моделями.Модель - это то, что вы где-то храните.Таким образом, вы будете иметь UserModel и PaneModel.И ваш контроллер будет реализовывать метод switchPane и метод входа в систему.Это хорошая идея, чтобы отделить этот метод в некоторых отдельных классах, есть много методов для выполнения этой задачи.Но я настоятельно рекомендую вам найти готовое решение.Не изобретай велосипед.

Answer 4

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

Модель повторяет то, что делает ваше приложение.Это не зависит ни от чего.Это то, что делает ваше приложение уникальным.

Представление отображает информацию для пользователя.Эта информация поступает из модели.Следовательно, представление зависит от модели.

Функция контроллера состоит в том, чтобы принимать входные данные от пользователя, отправлять этот запрос в соответствующие функциональные возможности модели и (обычно) принимать возвращаемое значение и предоставлять его длявид для рендеринга.Таким образом, контроллер обычно очень тесно связан с видом (ами), которые он обслуживает.Он также зависит от модели.

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

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

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

Answer 5

При таком базовом «функциональном дизайне» вам сложно в точности помочь, но вы, возможно, захотите больше подумать о том, что вы хотите.

• Модель пользователя - модель базы данных для пользователя. Содержит «проверить логин» Метод
• Просмотр страницы входа - Форма, макет и т. Д.
• Контроллер входа в систему - получает содержимое из формы, пытается войти в систему с помощью метода из объекта пользователя и создать указанного пользователя. объект

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