Что такое mvc java
Что такое MVC: рассказываем простыми словами
Современные сайты интерактивные и динамичные, то есть они реагируют на действия пользователя, обрабатывают его запросы и выдают результат. Так работают онлайн-сервисы, например, интернет-банкинг или онлайн-кинотеатр. Для создания интерактивных и динамичных сайтов обычно используется архитектурный паттерн MVC. В этой статье простыми словами объясняется суть этой модели.
Что такое модель MVC: теория
Статическая страница на HTML не умеет реагировать на действия пользователя. Для двухстороннего взаимодействия нужны динамические веб-страницы. MVC — ключ к пониманию разработки динамических веб-приложений, поэтому разработчику нужно знать эту модель.
MVC расшифровывается как модель-представление-контроллер (от англ. model-view-controller). Это способ организации кода, который предполагает выделение блоков, отвечающих за решение разных задач. Один блок отвечает за данные приложения, другой отвечает за внешний вид, а третий контролирует работу приложения. Компоненты MVC:
Чтобы лучше понять теоретическую информацию, используем абстрактное описание.
Разбираем MVC на примере магазина сэндвичей
Мы уже рассматривали работу с вложенными коллбэками на примере приготовления гамбургеров. Продолжаем традицию: разберем паттерн MVC на примере магазина сэндвичей.
Представьте, что вы пришли в магазин или кафе, где можно заказать сэндвич. В меню есть бутерброды с тунцом, индейкой и ветчиной. Вы заказываете сэндвич с индейкой.
Продавец или бармен с полуслова понимает вас. Он поворачивается в сторону кухни и говорит поварам, чтобы они приготовили сэндвич с индейкой.
У поваров под рукой есть разные продукты: тунец, индейка, ветчина, сыр, листья салата и другие ингредиенты, которые добавляют в бутерброды. Они выбирают только то, что нужно для вашего сэндвича с индейкой. Вы получаете свой заказ.
Покупку бутерброда можно описать через MVC:
Вы уже представляли готовый сэндвич с индейкой, когда заказывали его бармену. Это представление или view.
Справка: иногда модель MVC расшифровывают как модель-вид-контроллер. Это не ошибка, но всё-таки корректнее переводить view как представление.
Точно так же можно представить взаимодействие с сайтом. Когда вы заходите в «Фейсбук» и переходите по ссылке «Друзья», то заранее представляете результат перехода по ссылке. Это список ваших друзей.
Когда вы нажимаете на ссылку «Друзья», на сервер «Фейсбука» уходит запрос. В нём содержится просьба показать вам список друзей. Это очень похоже на просьбу продать вам бутерброд с индейкой. Это контроллер.
На сервере «Фейсбука» ваш запрос обрабатывается. Программа достаёт из базы данных всех ваших друзей, чтобы показать список. Это можно сравнить с кухней и поварами из примера с сэндвичем. Это модель.
«Фейсбук» берёт нужные ингредиенты из базы данных и готовит ваш заказ: список друзей. Тем же занимались повара на кухне магазина сэндвичей. Это снова представление или view.
Изучайте фронтенд- и бэкенд-разработку на JavaScript На Хекслете есть профессии «Фронтенд-программист» и «Node.js-программист». В процессе обучения на этих профессиях вы научитесь программировать на JavaScript, изучите современные инструменты для разработки фронтенд- и бэкенд-приложений, включая React, Redux, Express.js, Koa, PostgreSQL. Первые курсы в профессиях доступны бесплатно.
Паттерн MVC в реальной веб-разработке: простые примеры
Ниже представлены простые примеры MVC, которые используются в веб-фреймворках.
Контроллер
Контроллер обрабатывает входящие запросы. В фреймворке это может заключаться в определении конкретных URL, на которые попадает пользователь при переходе по ссылке или при нажатии кнопки.
Модель
Модель отвечает за данные, которые хранятся и обрабатываются на сервере.
Представление
Это HTML-шаблон, который возвращает сервер после обработки запроса. Если запрос корректно обрабатывается, вы получаете веб-страницу со списком друзей. Если запрос некорректный, вы попадаете на страницу ошибки 404.
Заключение
MVC — подход к проектированию приложения, который предполагает выделение кода в блоки модель, представление и контроллер. Контроллер обрабатывает входящие запросы. Модель достаёт из базы данных информацию, нужную для выполнения конкретных запросов. Представление определяет результат запроса, который получает пользователь.
Если у вас остались вопросы по MVC, задавайте их в комментариях.
Никогда не останавливайтесь: В программировании говорят, что нужно постоянно учиться даже для того, чтобы просто находиться на месте. Развивайтесь с нами — на Хекслете есть сотни курсов по разработке на разных языках и технологиях
С нуля до разработчика. Возвращаем деньги, если не удалось найти работу.
Что такое MVC: базовые концепции и пример приложения
Объясняем, что такое паттерн MVC и как он помогает упростить разработку.
MVC — это шаблон программирования, который позволяет разделить логику приложения на три части:
Может показаться, что это что-то запутанное, но на самом деле всё просто.
Пишет о программировании, в свободное время создает игры. Мечтает открыть свою студию и выпускать ламповые RPG.
Как работает MVC
Лучше всего понять концепцию MVC можно на реальном примере — ресторане с фастфудом. В нём посетители (пользователи) подходят к кассиру (одновременно вид и контроллер), видят меню и заказывают какое-нибудь блюдо.
Кассир проверяет, всё ли в порядке с заказом, и после оплаты передаёт нужные данные повару (модель). Повар готовит заказанное блюдо, хотя понятия не имеет о том, как выглядит посетитель, оплатил ли он заказ и так далее.
Когда модель закончит свою работу, она отправит результат в вид — обратно кассиру, который, в свою очередь, отдаст готовое блюдо посетителю.
Если же говорить о приложениях, то компоненты будут следующие:
Стоит также отметить, что реализация паттерна MVC может отличаться в зависимости от задачи. Например, в веб-разработке модель и вид взаимодействуют друг с другом через контроллер (как в примере с рестораном), а в приложениях модель может сама уведомлять вид, что нужно что-то изменить.
Зачем программистам нужен MVC
Этот паттерн разработки нужен для того, чтобы разделить логические части приложения и создавать их отдельно друг от друга. То есть писать независимые блоки кода, которые можно как угодно менять, не затрагивая другие.
Например, чтобы можно было переписать способ обработки данных, не меняя при этом способ их отображения. Это позволяет эффективно работать нескольким программистам — каждый занимается своим компонентом. При этом разработчику не нужно вникать в чужой код и его действия никак не повлияют на другие фрагменты приложения.
Независимым программистам MVC тоже будет полезен, потому что они смогут сосредоточиться на разработке одного компонента за раз. На курсе по С#-разработке мы учим писать тестируемые и поддерживаемые приложения, а паттерн MVC как раз упрощает эту задачу.
Практика: пишем
MVC-приложение
Чтобы лучше вникнуть в этот паттерн, стоит применить его на практике. Для этого создайте WPF-приложение и сверстайте такую форму:
Это и есть View — его видит пользователь. Тут есть кнопка, при нажатии на которую вызывается Controller:
Контроллер получает пользовательский ввод и обрабатывает данные. Он также может проверять права пользователя. Если валидация проходит успешно, данные передаются в Model:
Модель проводит с этими данными необходимые операции, а затем вызывает метод обновления вида:
Архитектура MVC в Java
В области веб-разработки Model-View-Controller является одним из самых обсуждаемых шаблонов проектирования в современном мире веб-программирования. Архитектура MVC изначально была включена в две основные среды веб-разработки – Struts и Ruby on Rails.
Что такое архитектура MVC в Java?
Проекты моделей, основанные на архитектуре MVC в Java, следуют шаблону проектирования MVC и отделяют логику приложения от пользовательского интерфейса при разработке программного обеспечения. Как следует из названия, шаблон MVC имеет три слоя:
Разделение программного приложения на эти три отдельных компонента является хорошей идеей по ряду причин.
Преимущества архитектуры
Архитектура MVC предлагает множество преимуществ для программиста при разработке приложений, которые включают в себя:
Реализация
Для реализации веб-приложения на основе шаблона проектирования MVC мы создадим:
Теперь давайте рассмотрим эти слои один за другим.
Слой модели
В шаблоне проектирования MVC модель представляет собой уровень данных, который определяет бизнес-логику системы, а также представляет состояние приложения. Объекты модели получают и сохраняют состояние модели в базе данных. На этом уровне мы применяем правила к данным, которые в конечном итоге представляют концепции, которыми управляет наше приложение. Теперь давайте создадим модель, используя Course Class.
Код прост для понимания и не требует пояснений. Он состоит из функций, чтобы получить/установить детали Course.
Уровень представления
Этот уровень шаблона проектирования MVC представляет выходные данные приложения или пользовательского интерфейса. Он отображает данные, извлеченные из слоя модели контроллером, и представляет данные пользователю при каждом запросе. Он получает всю необходимую информацию от контроллера и ему не нужно напрямую взаимодействовать с бизнес-уровнем. Давайте создадим представление, используя ClassView Class.
Этот код просто для печати значений на консоль. Далее у нас есть контроллер веб-приложения.
Уровень контроллера
Контроллер похож на интерфейс между моделью и представлением. Он получает пользовательские запросы от уровня представления и обрабатывает их, включая необходимые проверки. Затем запросы отправляются в модель для обработки данных. После обработки данные снова отправляются обратно в контроллер, а затем отображаются в представлении. Давайте создадим ClassContoller Class, который действует как контроллер.
Беглый взгляд на код скажет нам, что этот класс контроллера просто отвечает за вызов модели для получения/установки данных и обновления представления на основе этого.
Класс Main
Давайте назовем этот класс «MVCPatternDemo.java». Проверьте код ниже.
Приведенный выше класс извлекает данные Course из функции, используя которую пользователь вводит набор значений. Затем он помещает эти значения в модель Course. Затем он инициализирует представление, которое мы создали ранее в статье. Кроме того, он также вызывает класс CourseController и связывает его с классом Course и классом CourseView. Затем метод updateView(), являющийся частью контроллера, обновляет сведения о курсе на консоли. Проверьте вывод ниже.
Вывод
Архитектура MVC обеспечивает совершенно новый уровень модульности вашего кода, что делает его более удобным для чтения и сопровождения. Это подводит нас к концу этой статьи. Надеюсь, вам понятно все, что с вами поделились.
Что такое mvc java
— Ты уже серьезный программист. Поэтому сегодня у нас будет лекция про MVC.
В Controller’е сосредоточен весь код, который принимает решение, что менять в модели в ответ на действия пользователя. Например, пользователь принял решение закрыть программу, тогда надо сохранить данные модели в файл на диск. Или пользователь ввел новые данные. Тогда надо добавить их в модель, а модель потом уведомит все View об изменении данных, чтобы они отображали только актуальное их состояние.
— С точки зрения Java-программиста, можно сказать, что Model, View, Controller – это три группы классов, у которых:
а) у каждой части есть свое назначение;
б) связи между классами одной группы довольно сильные;
в) связи между группами довольно слабые;
г) способы взаимодействия частей довольно сильно регламентированы.
И вот тебе еще такая картинка:
— То, что ты это не применяешь сейчас, еще не значит, что не будешь применять в ближайшем будущем. Ты же тут учишься для того, чтобы работать пойти. И даже если эти знания не пригодятся тебе во время обучения, они точно пригодятся тебе во время работы.
А ведь тебя ждут еще реальные проекты и собеседования…
Мы тут сейчас с тобой разговариваем, а может через месяц ты уже работать будешь.
— Ты абсолютно прав, Билаабо. Я тебя внимательно слушаю.
— Подход MVC в архитектуре приложений встречается довольно часто. Ты должен это знать, чтобы вдруг не начать добавлять классы для View в Model, т.к. так удобнее.
Самое главное в любом проекте – это его архитектура. Твоя задача на нынешнем этапе — не столько сделать хорошую архитектуру, сколько научиться разбираться в чужой. До своей ты еще потом пару лет расти будешь. А чужую понимать надо. Сразу.
Когда в приложении используется стандартная архитектура, все становится гораздо понятнее. Зная архитектуру, ты знаешь, что где лежит, как все взаимодействует, как примерно программа работает, где добавить нужный тебе класс и где искать причину ошибки.
Но, вот если ты не знаком со стандартными подходами к архитектуре, то тебе даже самая лучшая архитектура ни о чем не скажет. Будешь смотреть, как крестьянин 15 века на новый автомобиль. Стандартный автомобиль.
— Ясно. Спасибо, за интересную лекцию, Билаабо.
MVC (Model View Controller) в JavaFX
MVC (Model View Controller / Модель Представление Контроллер) — это даже не паттерн, который имеет понятную реализацию (с примером кода), а некая концепция, призванная упростить разработку, поддержку и изменение программы. Именно поэтому все примеры кода имеют отношение только к конкретно решаемой задаче. Более того, реализация будет ещё зависеть и от используемого языка — в некоторых случаях «классическое» применение MVC может только усложнить код.
Я всегда воспринимал MVC как алгоритм, в котором определяются сущности под определенную задачу. До начала изучения Java, мне как-то не было особой нужды вдаваться во все эти тонкости, поскольку на Delphi, PHP или JavaScript нет ограничений и жестких рамок: задачу можно решать любыми способами. Но Ява заставляет использовать только классы ООП, а значит неизбежно возникает задача на логическое разделение кода.
«Классическое» понимание MVC
При описании MVC, обычно ссылаются на его реализацию в Smalltalk’е в 1978-88 годах. Поскольку в то время взаимодействие с пользователем происходила чуть ли не напрямую от опроса клавиатуры, а вывод на порт дисплея, то чтобы как-то упорядочить этот код и были придуманы разные методологии. Их основаная задача — избавление от спаггети-кода.
Те кто помнит программирование на Бейсике, прекрасно понимают о чем речь: все эти goto делали код совершенно нечитаемым. Со временем такой код был упорядочн с помощью функций, процедур, модулей/библиотек. Дальнейшее развитие привело к ООП, который ввел ограничение видимости, что почти решило проблему пространства имен.
С появлением визуального программирования, когда взаимодействие с пользователем перешло на совершенно другой уровень, концепция MVC немного поменялась, поскольку стало уже не так ясно за что отвечает View (Представление) и какая у него связь с Controller (Контролёр). И это породило жуткую путаницу, поскольку даже элементарная кнопка на форме может быть сразу и Представлением (сама себя отрисовывает), и Контролёром, поскольку может генерировать и обрабатывать события (методы), и даже Моделью, поскольку может содержать в себе необходимые данные.
Про Web вообще лучше и не упоминать. В PHP обычно всё в куче, а попытка сделать «по науке» только приводит к существенному разбуханию кода. 🙂
Если вы пытались найти в гугле примеры и описания MVC, то видели насколько велик «разброд и шатание» по этому вопросу. 🙂 Но, чтобы понять суть MVC достаточно лишь посмотреть на примеры, где нет абстракции, а есть реальный код.
MVC — в первую очередь Модель
Рассмотрим простейший пример. Пусть у нас будет форма с единственной кнопкой. При нажатии на кнопку, происходит подсчёт каждого нажатия и результат выводится в названии кнопки. Покажу на примере Delphi, поскольку Pascal очень прост для понимания.
Алгоритм будет такой — у каждого компонента есть свойство Tag, которое может содержать целое число. В нём и будем хранить количество нажатий. У кнопки создадим событие onClick, где и разместим код. Вот скриншот, где всё сразу видно:
Эта программа очень простая, но в ней хорошо видно, что кнопка по сути сама выполнила всю работу. Разделять её на MVC-компоненты нет смысла, пока мы не усложним задачу.
Пусть, например, у нас будет кнопка, которая будет запускать какой-то сложный расчет, данные для которого будут браться из Edit1 (текстовое поле), а результат выводиться в Label1.
Получится примерно так:
После задача ещё усложняется: нужно ввести ещё одну кнопку, которая делает тоже самое, но результат выводит в другой Label.
Очевидно, что здесь возникает дублирование кода, поскольку мы уже прописали весь код в Button1. Самое простое, что можно сделать — это copy/paste в Button2. Но, это не совсем правильно, поскольку в случае изменения алгоритма рассчета, придётся его править в нескольких местах. Логично вынести сам рассчет в отдельную функцию.
Поскольку функция должна принимать данные из Edit’ов, то мы её создаем в классе/объекте формы TForm1.
Функция m() завязана на Edit1, поэтому если станет задача использовать какой-то другой компонент, или даже его переименовать, придется править код этой функции. Чтобы этого не делать, нужно модернизировать m() так, чтобы она не была завязана на любые компоненты формы. В этом случае она должна принимать входящий текст как параметр.
Обратите внимание, что функция m() теперь не привязана к форме или любому другому элементу. Если мы захотим, то можем её вынести в отдельный модуль (unit) и подключать к любой другой форме.
Но при этом, компоненты формы видят эту функцию и могут её использовать.
С точки зрения MVC функция m() выполняет роль Модели. Одно из её ключевых свойст — Модель ничего не знает от том, кто её использует. Её задача — принять какие-то данные, их обработать и отдать результат.
Конечно этот пример безумно примитивный, но он хорошо показывает путь к MVC-приложению. Выделение части кода в Модель, позволяет значительно упростить поддержку программы. В более серьёзных программах, вместо функции обычно используются классы, модули и т.п.
Где же здесь Контролёр и Представление? Вот это — загадка природы. 🙂 Delphi позволяет оперировать ими одновременно. В теории сама форма и все её копомненты должны описываться Представлением. А контролёр должен отвечать за приём и обработку событий. Но те же кнопки — это довольно сложные объекты, которые сами могут выполнять различные задачи (внутри себя, как в первом примере), поэтому они по сути выполняются на уровне View без вмешательства Контролёра.
Именно такое неявное «поведение» Контролёра и Представления послужило причиной появления Model-View-Presenter, Model-View-ViewModel и т.п. шаблонов проектирования. В них Контролёр по сути заменяется модулем, обслуживающим Представление, но имеющим доступ к Модели.
Теперь посмотрим как дело обстоит в JavaFX.
MVC в JavaFX
Сразу хочу обратить внимание, что речь идёт именно о JavaFX, то есть программах, которые имеют нормальный графический интерфейс. Это немного отличается от консольных java-программ, которые могут организовать связь объектов чуть ли не в любом варианте.
При создании нового JavaFX-приложения генерируется каркас, как я показывал в прошлой статье. Я пока работаю в IntelliJ IDEA, но суть везде одинакова.
Создаётся несколько файлов:
При этом отстутствует Model.java и View.java, поэтому придется создать их самостоятельно.
Чтобы была конкретика, я покажу на примере простой программы, которая состоит из двух TextField, две кнопки указывающие на «операцию» и кнопку Go, которая выполняет «расчет». На выходе получается строчка, которая состоит из «поле1» + операция + «поле2» и выводит результат в метку формы.
Первое, что можно сделать — это выделить Модель (файл Model.java). Поскольку она ничего не должна знать о Контролёре и представлении, то Модель представляет собой обычный класс, который позже нужно будет использовать в других объектах. Привожу полный код файла.
Модель должна сама хранить своё состояние. В нашем примере это переменные, которые участвуют в конечном расчёте. Для их установки используются «сеттеры» (set-функции) — прямого доступа к переменным извне нет. Это довольно типовое построение классов.
Теперь разберёмся с Контролёром (файл Controller.java). Очевидно, что он должен принимать все on-события: у нас это нажатия кнопок (onAction). В этих методах мы прописываем методы модели.
Контролёр жестко завязан на форму, поэтому именно здесь мы получаем ссылки на TextField, которые используем для отправки в Модель. Кнопка Gо запускает отдельную функцию go(), которая выполняет сразу несколько действий. Можно было бы прописать всё непосредственно в onAction кнопки, но, помня, что программа может расшириться, лучше вынести алгоритмы расчета отдельно.
Остался последний компонент Представление (файл View.java). За что он вообще должен отвечать?
В современном представлении MVC компоненту View отводится роль «автоматического отображения» результата Модели. То есть, как только мы нажали кнопку Go, Контролер выполнил функцию go(), где срабатывает строчка model.go(); и Модель, после всех своих вычислений, должна «уведомить» View, что всё готово, забирай результат.
Данная схема описана в ООП-паттерне «Наблюдатель» (Observer). Чтобы она работала, View должна предварительно «зарегистрироваться» в Модели и иметь некий предопределенный метод, который и «дёргает» Модель, проходясь по списку «слушателей».
В нашем случае мы не будем реализовывать такой паттерн, поскольку у нас очень простая программа, где связи между объектами можно задать «вручную».
В JavaFX приложение строится немного «своеобразно». Когда main-функция принимает fxml-файл, то его контролёр (указанный в fxml-файле) имеет отношение только к этой форме. То есть это не Контролёр приложения, как можно было бы подумать, а Контролёр конкретной формы. По сути это не даже не Контролёр, а View, поскольку логика такова, что вначале создается отображение, а уже после идёт привязка к Контролёру. При этом View (класс/объект) как таковой не создаётся (это вообще внутренняя «кухня» Явы).
Но мы хотим всё-таки выделить View в отдельный класс, чтобы немного упростить Контролёр. При этом Представление должно получить доступ к Label, чтобы вывести результат.
Давайте создадим файл View.java, который выводит в Label любой текст. Например так:
В контролёре нужно теперь прописать объект View, чтобы получить к нему доступ:
Пока всё логчично, запускаем программу, но при нажатии на кнопку Go, получаем ошибку java.lang.NullPointerException, что означает null в org.maxsite.View.displayLabel — LabelResult в View неиницилизирована и равна null.
Как выйти из этой ситуации? Первый, довольно простой способ — «в лоб». Нужно объявить LabelResult в Controller, и явно его передавать в view.displayLabel вторым параметром. Таким образом View ничего не будет знать ни о Контролёре, ни о Модели и ей вообще всё равно что и как расположено на форме.
Минус этого подхода в том, что View оказывается жестко завязан на передаваемый тип Label для вывода результата. Если мы поменяем тип, то придется менять и Контролёр и Представление. Кроме того, Контролёру необходимо знать, то что ему особо и не нужно — LabelResult используется только для передачи во View. Было бы логичней, чтобы View сам решал куда следует выводить данные.
Очевидно, что проблема здесь только в области видимости в View метки LabelResult. А за область видимости в ООП «отвечает» механизм наследования (точнее расширения, но это не суть). Поэтому возникает простое решение — пусть Контролёр будет расширять View — за счёт этого, не нужно будет создавать новый объект, а поля формы станут доступны во View.
Таким образом наш View.java возвращается к первоначальному виду (код выше), а Контролер становится таким (привожу полный код, чтобы не запутаться):
Желающие поизучать код, могут скачать архив.
Очевидно, что в данной схеме можно реализовать и паттерн «Наблюдатель» между Моделью и Контролёром (который будет передавать данные в Представление). Сам Контролёр может подключать и другие классы, если нужно расширить функциональность (это другие ООП-паттерны).
PS. Почему это работает?
По какой причине View вдруг стал видеть LabelResult? Было бы логичней, если бы View расширялся от Controller, а тут «обратная» связь. Для меня самого это загадка, но думаю, что дело в загрузчике FXMLLoader в main-файле. При загрузке fxml-файла, FXMLLoader видит, что есть связь между Controller и View (класс и суперкласс), поэтому все аннотированные переменные и функции получают общую область видимости. Если убрать аннотацию @FXML у LabelResult, то программа перестает работать с той же ошибкой (null-инициализация).
Таким образом, данный способ построения MVC приложения годится только для JavaFX-программ. Для других видов нужно в main-файле явно создать зависимость между Моделью, Контролёром и Представлением, чтобы получить похожий результат.
Естественно, существуют и другие алгоритмы MVC, но на мой взгляд этот самый простой для понимания. 🙂