Типовые решения входных контроллеров

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

На входной контроллер возлагаются две основные обязанности: обработка HTTP-запроса и принятие решения о том, что с ним делать дальше, которые зачастую имеет смысл разделить, поручив первую функцию странице сервера, а вторую — вспомогательному объекту. В то же время типовое решение контроллер запросов (Front Controller) предусматривает использование единственного объекта, предназначенного для обработки всех запросов. Обработчик интерпретирует полученный адрес URL, определяет, с какого рода запросом он имеет дело, и создает отдельный объект для дальнейшего обслуживания запроса. Таким образом удается централизовать деятельность по обработке всех HTTP-запросов в рамках единого объекта и избежать необходимости изменения конфигурации Web-сервера в случае модификации структуры действий сайта.

Управление параллельными заданиями

Параллельное (concurrent) выполнение операций — одна из наиболее сложных дисциплин в области разработки программного обеспечения. Проблемы параллелизма возникают всякий раз, когда, скажем, несколько процессов или потоков вычислений предпринимают попытки манипуляций одними и теми же элементами данных. Восприятие множества параллельных операций затруднено, поскольку перечислить все возможные сценарии развития событий, способные привести к тем или иным неприятностям, крайне сложно. Более того, параллельные операции трудно тестировать.

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

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

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

Для иллюстрации концепций параллелизма приводятся примеры из области, которая, вероятно, читателю хорошо знакома: речь идет о системах контроля версий исходного кода, которые применяются командами разработчиков для координации вносимых изменений.