создание mvc приложения java
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, но на мой взгляд этот самый простой для понимания. 🙂
Архитектура 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 обеспечивает совершенно новый уровень модульности вашего кода, что делает его более удобным для чтения и сопровождения. Это подводит нас к концу этой статьи. Надеюсь, вам понятно все, что с вами поделились.
Учимся готовить: Spring 3 MVC + Spring Security + Hibernate
Добрый день! Меня зовут Антон Щастный.
Это моя очередная статья, посвящённая разработке веб приложений на Java. Хочу предложить вам сделать небольшую систему учёта клиентов, написанную с использованием фреймворка Spring и библиотеки Hibernate.
Что будет в приложении:
Будет простой менеджер контактов, позволяющий добавлять в базу новые записи, просматривать имеющиеся, удалять ненужные. Сведения будут храниться в базе данных. Доступ к приложению – через веб, с аутентификацией и авторизацией пользователей.
Что будем использовать:
В моей предыдущей статье о Spring MVC был упущен ряд моментов по использованию аннотаций в Java-коде и применению Maven для сборки проекта. В данной статье я попытался исправить упущение.
Цель статьи – показать начинающим веб разработчикам совместное использование различных технологий платформы Java.
Содержание
Архитектура разрабатываемого приложения.
1. Создание нового проекта в IDE
Проект будем разрабатывать в SpringSource Tool Suite (STS) – удобном редакторе, основанном на Eclipse IDE.
После установки STS создадим шаблонный проект:
File > New > Spring Template Project > Spring MVC Project.
Project name: ContactManager
Top level package: net.schastny.contactmanager
Редактор создаст шаблонный веб проект с базовыми настройками, имеющий следующую структуру:
| src/main/java | Java-классы приложения. |
| src/main/resources | Все остальные файлы (ресурсы), необходимые для работы: например файл настроек логгера log4j.xml, папка META-INF. |
| src/test/java | Папка для тестов JUnit. |
| src/test/resources | Папка ресурсов юнит-тестов. |
| src/main/webapp | Папка, в которой размещаются файлы веб составляющей менеджера контактов: дескриптор развёртывания приложения web.xml, xml-файлы с настройками фреймворка Spring, jsp-страницы. Внимание, статические ресурсы приложения: картинки, css, js-скрипты лежат в папке resources. |
| pom.xml | Файл настроек проекта для Maven’а, содержит наименование проекта и перечень зависимостей проекта от сторонних библиотек. |
Поменяем в настройках проекта (pom.xml) версию Spring с 3.0.4.RELEASE на 3.0.5.RELEASE.
Примечание: как создавать Maven-проекты вне IDE читайте здесь.
2. Создание структуры пакетов
| net.schastny.contactmanager.dao | Слой доступа к данным. В нём будем размещать Data Access Objects – объекты доступа к данным. |
| net.schastny.contactmanager.domain | Доменный слой. Именно здесь лежат POJO-классы, описывающие объекты-сущности системы. В нашем случае это класс Contact. |
| net.schastny.contactmanager.service | Сервис-слой приложения. Содержит интерфейсы, в которых описан функционал приложения. Также содержит одну или несколько практических реализаций этих интерфейсов. |
| net.schastny.contactmanager.web | Веб-слой приложения. Здесь лежат классы-контроллеры, описывающие порядок взаимодействия пользователя с системой через веб. |
Примечание: класс-контроллер, созданный редактором, можно удалить.
3. Добавление класса сущности в модель домена
Не забудьте добавить методы геттеры и сеттеры для свойств бина.
Добавим зависимости проекта в файл pom.xml. Обратите внимание, что класс из модели домена не будет зависить ни от Спринга, ни от Хибернейта.
Пояснение к использованным аннотациям.
| @Entity | Класс представляет объект, который нужно долговременно хранить. |
| @Table(name = «CONTACTS») | Свойства класса будем хранить в таблице CONTACTS. |
| @Column(name = «FIRSTNAME») | Это свойство будет храниться в столбце firstname. |
| @Id | Это поле уникальное для объектов, то есть по нему будем искать объекты. |
| @GeneratedValue | Значение этого поля будет назначаться не нами, а генерироваться автоматически. |
4. Слой доступа к данным
Интерфейс и практическая реализация объекта доступа к данным.
Обновим зависимости проекта в файле pom.xml. Добавим Хибернейт.
Пояснение к использованным аннотациям.
| @Repository | Аннотация показывает, что класс функционирует как репозиторий и требует наличия прозрачной трансляции исключений. Преимуществом трансляции исключений является то, что слой сервиса будет иметь дело с общей иерархией исключений от Спринга (DataAccessException) вне зависимости от используемых технологий доступа к данным в DAO слое. |
| @Autowired | Аннотация позволяет автоматически установить значение поля SessionFactory. |
5. Сервис-слой
Опишем интерфейс взаимодействия пользователя с системой.
Практическая реализация интерфейса сервиса – класс ContactServiceImpl.java.
Обновим зависимости проекта в файле pom.xml. Добавим поддержку транзакций.
Пояснение к использованным аннотациям.
| @Service | Мы используем данную аннотацию, чтобы объявить, что этот класс представляет сервис – компонент сервис-слоя. Сервис является подтипом класса @Component. Использование данной аннотации позволит искать бины-сервисы автоматически (смотрите далее в root-context.xml). |
| @Transactional | Перед исполнением метода помеченного данной аннотацией начинается транзакция, после выполнения метода транзакция коммитится, при выбрасывании RuntimeException откатывается. |
6. Добавление веб
Настройку веб приложения начнём с самого главного – с тьмы xml-файлов. В большом приложении очень удобно хранить различные настройки в разных файлах.
После xml-портянок напишем простенький контроллер.
Файлы настроек вы можете найти по ссылкам ниже.
| web.xml | Это дескриптор развертывания. Файл, который описывает настройки развертывания приложения на сервере. |
| spring/root-context.xml | Root Context. Контекст всего приложения. Бины, описанные здесь, будут доступны всем сервлетам и фильтрам. Также здесь следует описывать бины безопасности и доступа к данным (в нашей конфигурации они вынесены в отдельные файлы). |
| spring/data.xml | Файл с настройками ресурсов для работы с данными. |
| spring/security.xml | Файл с настройками безопасности. |
| spring/appServlet/servlet-context.xml | DispatcherServlet Context. Определяет настройки одного сервлета и бины, которые доступны только этому сервлету. |
| spring/appServlet/controllers.xml | Файл с настройками контроллеров для данного сервлета. |
Пояснение к используемым бинам.
| messageSource | Бин для обеспечения интернациолизации приложения. Ниже мы создадим файлы messages_en.properties и messages_ru.properties с локализованными сообщениями на русском и английском. |
| propertyConfigurer | Для загрузки файла с настройками БД jdbc.properties. |
| dataSource | Датасорс, используется для подключения к БД. Мы предоставляем класс jdbc-драйвера, имя пользователя, пароль, другие настройки. |
| sessionFactory | Это бин конфигурации Хибернейта. В файле hibernate.cfg.xml будут содержаться маппинги на классы сущностей. |
| transactionManager | Бин настройки менеджера транзакций. Мы используем менеджер транзакций для управления транзакциями приложения. |
Файлы:
/src/main/resources/messages_en.properties
/src/main/resources/messages_ru.properties
/src/main/resources/hibernate.cfg.xml
WEB-INF/jdbc.properties
7. Контроллер
Пояснение к использованным аннотациям.
| @Controller | Аннотация используется для магического превращения любого java класса в класс контроллера. Данный класс представляет собой компонент, похожий на обычный сервлет (HttpServlet) (работающий с объектами HttpServletRequest и HttpServletResponse), но с расширенными возможностями по применению в MVC-приложениях. |
| @RequestMapping | Аннотация используется для маппинга урл-адреса запроса на указанный метод или класс. Запрос можно маппить как на метод класса, так и на целый класс. Допускается указывать конкретный HTTP-метод, который будет обрабатываться (GET/POST), передавать параметры запроса. |
| @ModelAttribute | Аннотация, связывающая параметр метода или возвращаемое значение метода с атрибутом модели, которая будет использоваться при выводе jsp-страницы. |
| @PathVariable | Аннотация, которая показывает, что параметр метода должен быть связан с переменной из урл-адреса. |
8. Вид
9. Запуск приложения
До запуска системы нам необходимо сделать ещё две вещи:
Во-первых, создать базу данных для приложения и пользователя под неё в соответствии с настройками файла jdbc.properties:
Во-вторых, обновить зависимости в pom.xml.
Теперь запустим приложение на сервере: ContactManager > Run As > Run on Server > SpringSource tc Server Developer Edition v2.0.
Примечание: Проверьте кодировку базы данных, таблиц в БД, соединения с БД, кодировку проекта в редакторе, так как вместо родных кириллических букв в браузере могут появиться кракозябры.
Для отладки работы Хибернейта можете в файл src/main/resources/log4j.xml добавить следующую строку:
10. Безопасность
Обновим зависимости проекта в файле pom.xml. Добавим модули Spring Security.
Добавим в web.xml фильтр безопасности, действующий на всё приложение.
В целях безопасности страницу логина не следует помещать внутри папки WEB-INF, так что разместим её в корне веб приложения – в папке webapp.
webapp/login.jsp
Там же разместим страницу ошибки 403: webapp/error403.jsp
Подредактируем файл security.xml.
security.xml
Пояснение к сделанным настройкам в файле security.xml
Где хранить данные о пользователях
Можно прямо в конфигурационном файле, если их немного. Можно в базе данных, можно в LDAP-хранилище.
Пример записи (security.xml) при использовании БД для хранения паролей.
Пояснения к некоторым элементам.
| Поддержка мультисессии. После повторного запуска браузера не нужно заново логиниться. |
| Определение анонимного пользователя и наделение его ролями, так чтобы с ним можно было работать, как с обыкновенным пользователем приложения. |
| Хранение паролей в зашифрованном виде. В нашем приложении не используется. |
11. Заключение
Вот и всё! Осталось прикрутить дизайн, рюшечки на jQuery (статья для начинающих) и продавать поделку за деньги. Но это, дорогие мои читатели, уже совсем другая история.
После выполнения всех манипуляций у вас должна получиться следующая структура проекта:
Буду признателен за указанные ошибки и неточности в статье.
Использованные ресурсы:
1. Spring Recipes: A Problem-Solution Approach, Second Edition, Gary Mak, Ken Sipe, Josh Long, Daniel Rubio.
2. Create Spring 3 MVC Hibernate 3 Example using Maven in Eclipse,
3. The Spring Framework Reference Documentation,
4. Mastering Spring MVC 3 by Keith Donald.
Скачать готовый проект можно здесь, а базу данных для проекта — здесь.