Две модели JSP

В современных Java-проектах JSP используется не просто часто, а очень часто. Рынок есть рынок, и он диктует разработчикам свои законы: белорусские аутсорсинговые компании выполняют множество заказов на web-приложения, разрабатываемые с использованием JSP. Поэтому, думаю, рассказ об этой технологии будет интересен тем, кто ещё только планирует начать зарабатывать деньги программированием.


Введение в JSP

Поскольку статья предназначена всё-таки для тех, кто не имеет опыта работы с JSP, следует, я так думаю, для начала рассказать немного о самой сути данной технологии.

Аббревиатура JSP расшифровывается как Java Server Pages, или, говоря по-русски, серверные страницы на Java. Суть этой технологии заключается в том, что она позволяет использовать код, написанный на Java, внутри HTML-страниц, чтобы путём комбинирования Java и HTML создавать полноценные современные web-приложения.

Если вы думаете, что суть JSP есть мешанина из Java и HTML-кода, то вы немного ошибаетесь (хотя, конечно, именно так можно подумать из того, что изложено выше). В современных web-приложениях, написанных с использованием JSP, применяется только HTML-код, однако синтаксис этого HTML несколько расширен, по сравнению с обычными гипертекстовыми страницами. Расширен именно для того, чтобы можно было вызывать код Java-приложения при обработке HTML-страниц. На практике это реализуется в виде специальных тегов, которые распознаются в процессе обработки страницы и через которые вызывается Java-код, находящийся во внешних по отношении к самой странице модулях. Возможно, вам покажется, что такой подход неоправданно сложен, однако на самом деле это не так - а почему именно это не так, я объясню ниже.

 

Справедливости ради стоит заметить, что внедрять Java-код внутрь JSP-страницы напрямую действительно можно. Это называется JSP-скриптингом (JSP Scipting; к сожалению, адекватного русскоязычного термина, который был бы полностью аналогичен англоязычному, подобрать нельзя). Тем не менее, в современных web-приложениях JSP-скриптинг практически не используется, и тому есть ряд вполне веских причин, которые мы с вами обсудим чуть ниже.

Приходилось слышать мнение, что JSP - это некий аналог PHP, но только с использованием Java-синтаксиса. Что ж, вполне вероятно, что PHP-разработчики, которые столкнулись именно с JSP-скриптингом, могут воспринимать и всю технологию JSP именно в таком ключе. Однако, на самом деле, JSP - это отнюдь не аналог PHP, а в корне отличающаяся от PHP технология создания web-приложений.


Шаблон проектирования MVC

В современном процессе разработки любых приложений самым активным образом применяются шаблоны проектирования (англ. design patterns). Переоценить их удобство и полезность трудно, а потому везде, где можно, их стараются применять. Для web-приложений практически идеальным стал шаблон MVC, Model-View-Controller, или, если по-русски, модель-представление-контроллер (встречается, но весьма редко, также вариант перевода модель-представление-поведение).

Конечно, этот шаблон проектирования заслуживает отдельной статьи, и даже, наверное, не одной, однако сейчас я постараюсь кратко рассказать, в чём же состоит его суть.

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

Конечно, это всё выглядит, на первый взгляд, как бесконечно далёкая от реальной жизни абстракция, однако на самом деле это не совсем так. В реальных web-приложениях шаблон Model-View-Controller используется активно и успешно, и именно в его использовании и состоит преимущество JSP перед тем же, например, PHP.

Дело в том, что при использовании JSP-скриптинга (а именно в таком стиле и предполагается написание кода на PHP при разработке web-приложений с использованием этого языка программирования) использовать шаблон MVC становится попросту невозможно, поскольку в ту часть приложения, которая по своей сути является представлением, внедряется код, который относится к модели или даже контроллеру. Дело тут, впрочем, даже не столько в самом шаблоне MVC, сколько в неизбежной путанице, которая возникает тогда, когда весь код приложения помещается внутрь HTML-страниц. То, что было очень удобным при создании небольших приложений, становится настоящим бичом при создании приложений уже большего масштаба. Именно поэтому и приходится прибегать к структурированию, которое JSP поддерживает на очень и очень хорошем уровне.


Две альтернативы

При разработке web-приложения с использованием JSP перед руководителем проекта неизбежно встаёт вопрос о том, какую архитектуру приложения стоит, в конечном итоге, выбрать. Вопрос этот далеко не праздный, потому что от него, в конечном счёте, зависит успешное завершение проекта и, соответственно, всё то, что с этим успешным завершением непосредственно связано. Конечно, вам поначалу вряд ли придётся озадачиваться такими высокими материями, однако даже простому разработчику будет, скажем прямо, совсем не вредно знать, какие классические модели используются при разработке web-приложений на Java.

Таких моделей не сказать чтобы много - их всего две. Они, в общем-то, так и называются: JSP Model 1 и JSP Model 2 (их схемы приведены на иллюстрациях к статье). Давайте сначала рассмотрим каждую из них, а потому уже поговорим об их достоинствах и недостатках.

В JSP Model 1, как видно из приведенной схемы, при получении запроса от клиента JSP-страница конструирует нужные ей экземпляры JavaBean-классов, которые затем уже получают данные из базы данных и, обработав эти данные некоторым образом, передают их обратно JSP-страницам.

В JSP Model 2, в отличие от JSP Model 1, мы видим на схеме полноценную реализацию шаблона модель-представление-контроллер. Именно эти части приложения в ипостаси сервлета (контроллер), JavaBean-классов (модель) и JSP-страниц (представление) можно увидеть на предлагаемой схеме внутри приложения. Как видно из всё той же схемы, при запросе пользователя первым реагирует сервлет, который, взаимодействуя сложным образом с другими компонентами приложения, получает, наконец, из базы данных через JavaBean-классы какую-то информацию (либо же записывает её туда, что сейчас не столь уж принципиально), которая затем передаётся JSP-страницей в качестве ответа на пользовательский запрос.

В общем-то, говоря о специфике каждой из моделей web-приложений на JSP, стоит отметить, в первую очередь, что JSP Model 1 является моделью, ориентированной на JSP-страницы, которые и осуществляют основную работу в программе. Вся бизнес-логика приложения присутствует в явном или неявном виде на JSP-странице, что вряд ли можно считать плюсом. Что касается JSP Model 2, то здесь, позволю себе повториться, мы имеем дело с шаблоном модель-представление-контроллер. О преимуществах его использования я довольно-таки подробно рассказывал выше, однако здесь стоит упомянуть ещё некоторые из них. Во-первых, с приложениями, организованными по JSP Model 2, гораздо проще иметь дело при проведении каких-то изменений непосредственно на самих JSP-страницах. Мы вольны менять их, в общем-то, практически так, как захотим, без оглядки на такие мелочи жизни, как контроллер и модель. Модульность позволяет нам не затрагивать бизнес-логику при изменении пользовательского интерфейса. Кроме того, разработчик, работающий над реализацией бизнес-логики, может совершенно не задумываться над проблемами реализации интерфейса, равно как и разработчик, реализующий интерфейс, может не особенно беспокоиться насчёт бизнес-логики разрабатываемого командой приложения.


Резюмируем

В общем-то, из всего сказанного выше можно сделать только один вывод: возникшая исторически раньше JSP Model 1 в наше время уже не так актуальна, как JSP Model 2. И дело здесь, в общем-то, не в росте размеров проектов, которые пишутся с использованием JSP: JSP Model 2 будет удобнее и на большинстве небольших проектов, поскольку эта модель гибче, чем JSP Model 1.

Что касается самой технологии JSP, то, конечно, эта статья не может рассматриваться как хороший старт для того, кто ещё ни разу ничего не писал с использованием этой технологии, в силу некоторой своей абстрактности. Тем не менее, я надеюсь на то, что она поможет начинающим изучать JSP глубже понять некоторые особенности построения web-приложений на основе этой технологии, а также привлечёт их внимание к тому факту, что в современной индустрии разработки программного обеспечения шаблоны проектирования играют очень и очень важную роль.

Вадим СТАНКЕВИЧ,
dreamdrusch@tut.by

Версия для печатиВерсия для печати

Номер: 

42 за 2008 год

Рубрика: 

Software
Заметили ошибку? Выделите ее мышкой и нажмите Ctrl+Enter!
 

Комментарии

Аватар пользователя Виталий
Центральный контроллер обычно проблематично использовать, т.к. он отвечает за маршрутизацию запроса нескольким страницам, а формат запроса обычно как раз и зависит от конкретной страницы. Поэтому совершенно не практично создавать один универсальный контроллер из-за трудностей при суппорте и добавлении нового функционала. Если проанализировать возможные модели организации веб-приложения, такие как компонентная модель, модель, основанная на веб-службах (для Ajax), а также упомянутая в данной статье Model2, то можно прийти к выводу, что наилучшим вариантом является компонентная модель для веб-приложений с перезагрузкой страниц (с веб-службами в случае использования Ajax). Оптимальный вариант компонентной модели заключается в использовании страницы-контроллера. При этом части модели MVC состоят из следующих сущностей: View - UL каждого из компонентов, Controller - контроллер каждого из компонентов, а также страница-контроллер, организующая работу и взаимодействие компонентов на основе механизма событий(компоненты ничего не знают друг о друге), Model - общий уровень бизнес логики, доступный для контроллера каждого из компонентов. Обычно контроллеры компонентов называют контроллами, а их View - скинами. При такой структуре достигается полная независимость и расширяемость каждой из частей модели, а издержки проектирования окупаются сторицей. :-)
Аватар пользователя Savely
Нда... Асилил, в целом понял. Почуствовал себя динозавром. Слава Богу, что деньги платят не только за Web-программирование...

Аватар пользователя Al
Умри - ясней не скажешь! Лишь бы издержки окупались! :))