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-приложений.
|
