Общая объектно-ориентированная библиотека: Project ASP API
Для упрощения использования любой новой технологии (и для описанных выше конвертаций ASP проекта в проект JSP/PHP) жизненно необходимо абстрагировать системные средства ASP в библиотеку общего пользования. Эту библиотеку можно специально приспособить под конкретный проект, для значительного упрощения ее применения. Рассмотрим типичных кандидатов на помещение в общую, объектно-ориентированную, библиотеку.
Config - это объект, который хранит все настройки, общие для сайта в целом. Реально, они будут записываться при старте сайта в ASP коллекцию Application(), например из конфигурационного XML или INI-файла или просто из global.asa. Но весь остальной ASP-код работает с конфигурационными параметрами исключительно через этот объект и к способу хранения/чтения этих параметров никак не привязан. Параметры конфигурации могут быть представлены, в объекте Config, как атрибуты объекта и/или как методы getStr("Section","Entry","Default"), getInt(...), getBool(...), и т.д.
ConfigUser - этот объект хранит переменные текущей сессии пользователя. Абстрагируя переменные сессии в этот объект, мы получаем независимость от способа хранения переменных сессии. Мы можем как угодно менять и комбинировать способы хранения этих переменных: коллекция Session(), Cookies, Database, поля HTML формы - что угодно. При этом основной код будет оставаться неизменным. Доступ к переменным можно организовать аналогично объекту Config, но уже с возможностью модификации этих переменных - getStr(...)/setStr(...), и т.д.
Тут возникает весьма неоднозначный вопрос - об именовании объектов. Как в ASP, так и в сервлетах/JSP общую конфигурацию рекомендуется записывать в коллекцию Application (application), а пользовательскую - в Session (session). Проблема в том, что концепции коллекций Application и Session подразумевают то, что туда можно записать все, что угодно и время жизни этих коллекций ограничено. Они универсальны, и не приспособлены специально для хранения конфигураций.
Поэтому назвать наши конфигурационные объекты надо как-то по-другому (не application и session). Например: ConfigApp/ConfigUser, AppProperties/UserProperties, GlobalProperties/SessionProperties и т.п. Еще один фактор - это сокращения в названиях. Это не очень хороший стиль, поскольку многие сокращения могут оказаться непрозрачны для некоторых разработчиков.
Вопрос о поиске хороших наименований является очень тяжелым и субъективным. Автор будет весьма признателен, если кто-то предложит удачные короткие названия для двух вышеприведенных объектов, которые встречаются почти во всех проектах.
ObjectFactory - если задуматься о будущем, то запись Server.CreateObject(...) в основном ASP коде покажется весьма ограничивающим фактором. Если понадобится использовать J2EE CAS COM Bridge (мост от Sun для использования EJB и обычных Java-классов через COM), то процесс создание объекта уже будет отличатся, и запишется так (JScript):
_factory = Server.CreateObject("J2EECAS.JavaClassLoaderFactory");
_classloader = _factory.CreateClassLoader();
_class = _classloader.FindClass("java.lang.String");
objJavaStr = _class.New();
И основной ASP код придется переписывать. Для мостов CORBA придется использовать другую запись. Нет, конечно, может быть не все так плохо, и возможно для данного конкретного проекта никогда не понадобится связь ни с EJB, ни с CORBA, ни что-нибудь еще (пострашнее :) ). Но кто знает...
Если вы все же решились абстрагировать и эту сторону проектной реальности, то ObjectFactory, минимально должен предоставлять 2 метода - создание и удаление объекта. Не важно что обычно удалением объектов занимался сборщик мусора. Пусть даже наш метод удаления объекта на самом деле ничего не делает - это не важно. Пусть он будет, и пусть он вызывается когда нужно - будущее нас рассудит.
У каждого объекта 2-nd tier должен быть псевдоним для его идентификации при обращении к ObjectFactory. Например в основном коде будет запись ObjectFactory.CreateObject("MailSender"); И только ObjectFactory на самом деле будт знать что это COM объект с AppId "com.sa.soft.utils.SendMail005".
Параллельно ObjectFactory можно нагрузить мелкими функциями - контролем всяческих пулов и кэшей, проверкой валидности объекта, etc.
И, чтобы уж совсем по-модному, доступ к вышеописанным объектам должен осуществляться через единственный объект-ядро:
Core - этот объект должен присутствовать во всех ASP страницах основного кода в единственном экземпляре (синглетонами также должны быть объекты Config, ConfigUser и ObjectFactory. а вот DB-объекты - необязательно). Главная задача объекта Core - создавать и возвращать все описанные выше объекты написанной вами библиотеки, гордо именуемой Project ASP API.
Например, Core.getConfigApp() создаст объект ConfigApp и вернет на него ссылку. Повторный вызов не будет создавать объект повторно, а вернет ту же ссылку (чтобы гарантировать, что ConfigApp останется синглетоном). Помимо того, что основной ASP-код станет более понятным, мы получим весьма полезный эффект. Core может запоминать ссылки на все созданные им объекты. И вызвав в конце ASP-страницы метод, например, Core.close(), мы получим гарантированное
закрытие всех объектов, даже если мы забыли закрыть их в основном коде. Для объектов работы с базой данных это особенно критично.
Конечно, стандартным должен быть и объект для работы с источником данных, но о нем позднее.
