Проблема ASP-приложений: смесь HTML, SQL и VBScript, с трудом поддающаяся осмыслению

Появление Active Server Pages(ASP) для многих стало знаменательным событием. Технологии-конкуренты - Personal (в начале подразумевался Perl) Home Pages(PHP), Java Server Pages(JSP), ColdFusion Markup Language(CFML) и PL/SQL Server Pages (PSP) появились позднее и, частично, носили подражательный характер (что не уменьшает их достоинств). Наиболее интересными и полезными качествами, которыми привлекала технология ASP, можно считать:

удобный способ объединение Server-Side Script c HTML;

скриптовый подход (интерпретируемый язык) - т.е. файл с исходным кодом ASP одновременно является его исполняемым файлом, что упрощает процессы разработки и поддержки;

концепция "Session" - переменные для каждого пользовательского соединения, как удачное решение вечной проблемы stateless-протокола HTTP;

возможность организации распределенной архитектуры на основе инфраструктуры COM (Component Object Model), DCOM, COM+. Дополнительные возможности, предоставляемые Microsoft Transaction Server (MTS) - такие, например, как контекст объектов, пул и т.д.;

удобный набор объектов-утилит: Server, Application, Request, Response, Session, ObjectContext.

Главной идеей и достоинством ASP сразу виделась возможность встраивать программный код, обрабатываемый сервером, непосредственно в HTML страницу (а не наоборот, как предлагал CGI). При всех больших возможностях этого подхода, он скрывает серьезную ловушку. ASP-файл, написанный подобным образом, может поддерживать только человек, хорошо владеющий как ASP-программированием, так и HTML. Что накладывает жесткие требования на подбор кадров. Встроенный в ASP-страницы SQL усугубляет ситуацию, усложняя код и делая его непереносимым на другой источник данных.

    К тому же, полученный подобным образом ASP-файл, в конкретный момент времени, может править только 1 человек. Грубо говоря, это означает, что если работает программист - то дизайнер спит. А если файл правит дизайнер - то спит программист. Т.е. наблюдается невозможность распределения труда там, где она потенциально возможна, и могла бы ускорить разработку.

    Применяемый, в быстро развивающемся Internet, такой неоднозначный подход, как Rapid Application Development (RAD), еще больше обостряет ситуацию. Проекты часто разрабатываются на скорую руку - лишь бы что-то быстро показать инвесторам, а затем уже пересматривается архитектура, приглашаются профессиональные дизайнеры. Но эти дизайнеры совершенно бессильны что-либо исправить в той кошмарной смеси HTML, SQL и VB/J/PerlScript которая, в общем-то, разрабатывалась как прототип, и была, почему-то, принята за конечный продукт (по горячему желанию руководства), в котором надо всего лишь "немного улучшить дизайн".

    Вышеописанное несколько напоминает распространенную ситуацию с популярными средствами RAD в области разработки обычных Standalone-приложений. Такими как Delphi, C++Builder, Centura Team Developer, VisualBasic, и т.д. Когда код бизнес-логики оказывается "размазанным" по различным обработчикам элементов пользовательского интерфейса. Навсегда связывая проект с имеющейся технологией и архитектурой и затрудняя поддержку и расширение кода. Масштабирование(т.е., например, вынесение бизнес-логики в объекты 2nd tier - COM,CORBA,EJB), фактически, становится невыполнимым, поскольку код бизнес-логики придется, в буквальном смысле, "соскабливать" с различных ComboBoxes, TextFields, Buttons, и т.п.

    Таким "размазыванием" страдают и современные разработки на ASP. С другой стороны, представляется вполне возможным избежать подобной ситуации. Просто осознавая с самого начала возможные неприятности в будущем, и закладывая в проект дополнительные степени свободы. Например, всегда хорошо иметь, про запас, возможность быстро сменить инфраструктуру Web-приложения - т.е., например, перейти с ASP на JSP или PHP, без переписывания основного кода.  И эта возможность - вполне реальный эффект (причем м.б. даже побочный) хорошей организации проекта.

Для начала, сформулируем проблемы, присущие многим ASP-проектам, с которыми мы будем бороться:

Смесь бизнес-кода и HTML приводит к трудностям поддержки и того и другого;

Наличие большого количества DB-зависимого кода в ASP-страницах привязывает их к источнику данных;

Перегруженность ASP-страниц функциональностью приводит к перегрузкам IIS (хотя это можно решить кластеризацией IIS);

Смысловая перегрузка ASP-страниц затрудняет их поддержку;

Хранение бизнес-логики в ASP-страницах в "размазанном" виде приводит к затруднению ее вынесения в объекты 2-nd tier (при необходимости масштабирования и поддержки разных видов 1st tier-клиентов);

Полная зависимость кода проекта от самой технологии ASP

Что предлагается делать в этой статье (кратко):

Вынести HTML из ASP-страниц в отдельные файлы;

Вынести SQL из ASP-страниц;

Абстрагировать Microsoft ASP-специфические возможности в объекты общей библиотеки;

Организовать все часто используемые функции в виде методов общей объектно-ориентированной библиотеки;

Использовать JScript или PerlScript и отслеживать пути быстрого перехода на JSP/PHP, при возникновении подобной необходимости.

Содержание раздела