Главная
страница 1страница 2страница 3 ... страница 5страница 6

1 Обзор существующих методик

1.1 Эволюция web-разработки

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





Рисунок 1. Статическое web-приложение
Первые динамические web-приложения стали появляться при появлении технологии CGI (от англ. Common Gateway Interface – «общий интерфейс шлюза») – стандарт интерфейса, используемого для связи внешней программы с web-сервером. Интерфейс был разработан таким образом, чтобы можно было использовать любой язык программирования, который может работать со стандартными устройствами ввода/вывода[3]. Программа-клиент обращается к серверу, который по адресу выбирает запрошенную CGI-программу (в терминологии CGI именуемую «шлюзом» или просто «скриптом»), выполняет ее и возвращает результат клиенту (см. Рисунок 2).

С разработкой CGI связано появление механизма пользовательских сессий. Сессия представляет собой набор пользовательских данных, которые хранятся в течение сеанса пользователя. Эти данные уникальны для различных экземпляров пользовательских сессий. На клиентской стороне пользовательская сессия идентифицируется при помощи HTTP-cookie или при помощи параметра, передаваемого с запросом.





Рисунок 2. Динамическое web-приложение, выполняющееся

множеством CGI-программ

Дальнейшая эволюция разработки web-приложений связана с организацией разобщенного множества скриптов в архитектуру MVC (от англ. Model-View-Controller – «Модель-Представление-Поведение»), в которой модель данных приложения, пользовательский интерфейс и управляющая логика разделены на три отдельных компонента так, что модификация одного из компонентов оказывает минимальное воздействие на другие компоненты. В использовании MVC для web-приложений важным является наличие контроллера событий, который по клиентскому запросу передает управление одному из зарегистрированных в системе обработчиков, который, по сути, является контроллером MVC (см. Рисунок 3). Таким образом, от использования множества связанных исключительно логически CGI-программ был сделан шаг к строгой организации архитектуры web-приложения.





Рисунок 3. Динамическое событийно-ориентированное

web-приложение

Как видно, web-разработка имеет ряд отличий от разработки «настольных приложений», хотя постепенно эти подходы сближаются. Свидетельством тому может служить возрастающая популярность технологии AJAX (от англ. Asynchronous JavaScript and XML – «асинхронный JavaScript и XML»). Это подход к построению интерактивных пользовательских интерфейсов web-приложений, заключающийся в «фоновом» (без перезагрузки страницы) обмене данными программы-клиента с web-сервером. Таким образом, приложение может функционировать как настольное. Этот подход ориентирован на программирование на клиенте и с точки зрения серверного программирования не привносит ничего нового, кроме формата представления. По сути, на событие, произошедшее на странице, генерируется запрос к web-серверу, после обработки которого возвращается ответ клиентскому обработчику, который в свою очередь меняет представление на клиенте.

Следующим же шагом развития web-разработки в направлении разработки «настольных приложений» видится в такой организации архитектуры приложения, при которой логика приложения описывается прямым потоком команд независимо от транзакционной природы HTTP (см. Рисунок 4).



Рисунок 4. Динамическое web-приложение, выполняющееся

в прямом потоке команд

1.2 Проблемы традиционного подхода


Model-View-Controller (MVC) является традиционной моделью для разработки интерактивных приложений, в том числе для Web. Этот хорошо известный подход делит интерактивное приложение в три отдельных слоя:

  • Модель (англ. Model) – слой данных приложения и бизнес-логики.

  • Представление (англ. View) – слой представления данных и ввода данных.

  • Контроллер (англ. Controller) – слой обработки запросов и управления потоком.

Итак, типичное web-приложение состоит из четко определенных последовательностей транзакций между клиентом и сервером, выраженных в отправке страниц и ожидании данных от пользователя. В этом смысле, web-приложения имеют сходство с конечным автоматом, переводящем приложение в следующее состояние по пришедшему от клиента событию. Эта модель и есть то, что собой представляет контроллер[4].

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

В итоге обнаруживается ряд проблем, связанных с тем, что web-приложение, реализованное способом, описанным выше, представляет собой конечный автомат[1]:


  • В зависимости от размеров конечного автомата и количества данных, необходимых для сохранения текущего состояния для каждого клиента, логика приложения становится излишне загроможденной и сложной.

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

  • Аналогичная проблема может возникнуть в том случае, если web-приложение собирает информацию от пользователя через последовательность отправляемых форм. Если генерация следующей формы зависит от данных, полученных на предыдущих шагах, приложение должно отслеживать все запросы, хранить все данные (учитывая последовательность), полученные на предыдущих шагах, и возвращать корректные ответы на каждый такой запрос.

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

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

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

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





Рисунок 5. Обработка многошаговой бизнес-функции

при MVC-подходе
Предположим, пользователь ввёл информацию для подсчета налогов и отправил запрос серверу. Система, обработав эти данные, изменила текущую стоимость и вернула пользователю форму для ввода адреса доставки. Теперь пользователь послушно ввел адрес доставки и отправил данные на сервер, который в свою очередь пересчитал сумму и вернул пользователю форму с выбором способа платежа. Но пользователь вместо ожидаемых от него действий по вводу адрес решает вернуться назад, после чего вводит иную информацию об адресе доставки и отправляет новый запрос для пересчета. Система вновь меняет текущую (однажды измененную) стоимость в соответствии с новыми данными. В результате чего в расчеты вкрадывается ошибка (см. Рисунок 6).



Рисунок 6. Пример использования кнопки «Назад»,

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



Рисунок 7. Пример копирования экземпляра приложения,

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

Хотя использование MVC-модели совместно с событийно-ориентированной дает многочисленные преимущества, оно также приводит к тому, что бизнес-функциональность разносится по различным модулям, что делает довольно сложным разработку, понимание и поддержку крупных web-приложений.



<< предыдущая страница   следующая страница >>
Смотрите также:
С. А. Юшкеев Электронная версия дипломной работы помещена в электронную библиотеку. Файл
392.45kb.
6 стр.
Памятка системному администратору 7 Работа с базой данных 11 Состав и структура базы 11 Сортировка документов 17
471.58kb.
8 стр.
Пример оформления задания по дипломной работе
29.14kb.
1 стр.
Руководство по технической поддержке Руководство касается программы e-staff Рекрутер, версия 2 Однопользовательская версия
55.13kb.
1 стр.
Требования по оформлению
150.55kb.
1 стр.
Арутюнян гагик гарушевич конституционный суд
3096.3kb.
13 стр.
Название издания
35.49kb.
1 стр.
Дипломной работы
53.73kb.
1 стр.
Методические указания к выполнению дипломной работы
345.3kb.
1 стр.
Old Good Stalker Mod: Clear Sky история изменений версия 8 Community
553.99kb.
3 стр.
Положение о дипломной работе студента факультета психологии и социальной работы по специальности педагогика и психология
254.18kb.
1 стр.
Электронная версия
45.86kb.
1 стр.