Розробка складних Web-додатків на прикладі Microsoft Active Server Pages

Введення


Проблема 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, можна вважати:



Головною ідеєю та гідністю 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-проектам, з якими ми будемо боротися:



Що пропонується робити в цій статті (коротко):


 

Тепер, спробуємо виявити основні критерії ідеальної розподіленої архітектури:



Проблема ASP полягає в тому, що суміш скрипта бізнес-логіки, HTML і SQL представляє собою 2-х рівневу архітектуру (клієнт-сервер), яка з завданнями Web-додатків не справляється. Тому ми запропонуємо спосіб, як розділити ASP на три складові – ASP-код з бізнес-логікою, HTML і SQL.


ASP-програмування: порівняння VBScript, JScript, PerlScript


ASP-сторінки, чомусь, завжди пов'язують зі скриптом VBScript. Хоча це, напевно, найгірший з можливих варіантів. ASP можуть бути написані на будь-якому WSH (Windows Scription Host)-сумісному скриптовій мовою. Розглянемо 3 варіанти – VBScript, JScript, PerlScript. Перші два – VBScript & JScript підтримуються Miscrosoft, і не вимагають додаткових інсталяцій. PerlScript автоматично встановлюється при інсталяції ActivePerl. Порівняємо ці три варіанти.


VBScript


До небагатьом переваг (вельми неоднозначним) VBScript можна віднести те, що він простий для використання VisualBasic-програмістами. Якщо об'єкти 2nd tier пишуться як COM-об'єкти на VisualBasic, це може служити виправданням використання VBScript. Оскільки утворюється якийсь "корпоративний стандарт". Мова Basic, сам по собі, є прекрасною мовою для навчання програмуванню, на якому виросло не одне покоління програмістів. Однак, безпосередньо VBScript, не сприяє появі хорошого стилю програмування і тому стимулює крах проектів середньої та великої складності. Напевно, гіршим обмеженням є відсутність можливості об'єктно-орієнтованого програмування, що дуже критично для великих проектів. Якщо, все-таки, вирішено використовувати VBScript, слід приділити ретельне увагу акуратності при написанні коду, коментарям, відступам, зрозумілим назвам процедур, функції і змінних, хорошому документування. Це важливо при будь-якому програмуванні, але для VBScript це актуально подвійно. Чи не слід також користуватися незалежністю від регістру мови VBScript.


JScript (JavaScript)


Одним з новаторських винаходів фірми Netscape став скриптова мова JavaScript. Його синтаксис офіційно грунтується на надзвичайно популярному зараз мові Java. А це, у свою чергу, говорить про схожість з C і C + +. Особливий інтерес в JavaScript представляє оригінальна система динамічного створення об'єктів, що дозволять застосовувати об'єктно-орієнтований підхід. Незважаючи на відсутність інкапсуляції, дивне успадкування і необмежений поліморфізм (перевірки типів в JavaScript немає), застосування об'єктів виводить програмування ASP-сторінок на більш високий рівень, дозволяючи використовувати стандартні патерни проектування, спрощуючи код, і робить його більш логічним, розширюваним і стерпним. Можна, наприклад, створювати оболонки (які ще називають адаптерами або врапперамі) COM-об'єктів (того ж ADODB), більш зручні для застосування, і абстрагуйтеся основний ASP-код від цього-самого COM-об'єкта (дозволяючи, при необхідності, легко замінити його на інший об'єкт 2nd tier). JScript є клоном мови JavaScript від Microsoft. Відмінності JavaScript і JScript мінімальні, проте їх слід знати (відмінності описані в документації по JScript) і обходити (або абстрагувати), оскільки застосування JScript в ASP відкриває унікальну перспективу – на можливість простого перекладу Web-додатки, майже без переписування основного коду, на технологію JSP (Java Server Pages). Це не означає, що ми збираємося кидати ASP і терміново переходити на JSP. Просто, в сучасних умовах, бути не прив'язаним до єдиної платформі і / або технології – дуже цінна властивість проекту, яке, можливо, врятує його від загибелі. Якщо грамотно абстрагувати ASP-і Windows-залежний код в загальні бібліотеки, то, переписавши тільки ці бібліотеки, ми, теоретично, отримаємо JSP-сайт. (JSP сторінки можуть бути написані на JavaScript, а конструкції <%…%>, <%=…%> Схожі і в ASP і в JSP). Це, однак, не відноситься до об'єктів 2nd tier, які переводити доведеться окремо. Перевагою JavaScript можна вважати його застосування на стороні клієнта (DHTML в Web-броузері), що дозволяє створити "корпоративний стандарт". Тобто програміст-розробник може застосовувати єдину технологію на стороні клієнта і сервера (VBScript також можна використовувати на стороні клієнта, для броузера Internet Explorer, але це, звичайно, не практикується). Якщо розробки в компанії ведуться на Java, С або С + +, то JavaScript вельми гармонійно впишеться в робоче середовище. Недоліком конкретної реалізації JScript можна вважати відсутність аналога VBScript-функції chrB (), що обмежує можливість роботи з однобайтові потоками даних. Що, з іншого боку, стимулює винесення складного коду в об'єкти 2-nd tier.


PerlScript (ActivePerl)


З'явившись як мова для написання UNIX-скриптів, Perl знайшов нове покликання в Web-розробках завдяки своїй простоті, унікальним можливостям для роботи з рядками, великій кількості бібліотек і своєї безкоштовності. Використовувати Perl як PerlScript в ASP трохи ефективніше, ніж як CGI або ISAPI, оскільки відкриває доступ до стандартних і вельми корисним ASP-об'єктів (Server, Application, Session, etc.). Perl підтримує об'єктно-орієнтоване програмування, що дає йому переваги, описані вище для JavaScript. Недоліком (умовним) використання PerlScript є необхідність його установки на сервер (ускладнення deployment), а також те, що це вільно-розповсюджуваний продукт, без жодних гарантій. З іншого боку, для країн СНД ця характеристика властива більшості програмних продуктів, і тому цей недолік неактуальний. Вирішувати, хто довше проіснує і буде продовжувати випускати оновлені версії своїх продуктів – Microsoft або ActiveState (розробник ActivePerl) – теж справа невдячна. Тому варто спочатку закладати в проект можливість для переходу на конкуруючу технологію. Для ASP + PerlScript ця технологія – PHP. Так само, як ASP + JScript можна перевести на JSP, так і ASP + PerlScript можна перевести на PHP, оскільки скриптова мова PHP з синтаксису близький до Perl. Цей перехід бачиться трохи більш складним, ніж ASP + JScript-> JSP, але цілком здійсненним. До неоднозначним фактами можна віднести наявність у Perl великої кількості бібліотек. Незважаючи на удавану явну перевагу, концентрація занадто великої функціональності в ASP-сторінках (до чого схиляють Perl-бібліотеки) призводить до порушення балансу розподіленої системи. Замість того, щоб виносити функціональність у 2nd tier об'єкти, розробники розміщують складний і ресурсномісткий код в ASP-файли, в результаті система стає немасштабіруемой, а IIS – перевантаженим. Вирішенням цієї проблеми виглядає розробка 2nd tier COM-об'єктів на тому ж Perl (можливість писати COM-об'єкти на Perl ActiveState пропонувала, на момент написання статті, за 110 $). Знову ж таки, ми маємо корпоративний стандарт – ASP + PerlScript & COM-об'єкти на Perl, з усіма перевагами корпоративних стандартів.


Загальні порівняльні характеристики:













































ASP Script:

VBScript

JScript

PerlScript
Об'єктно-орієнтоване програмування Ні Так Так
2nd tier на COM Так Так Так
2nd tier на CORBA Тільки через мости Тільки через мости Так
2nd tier на EJB Тільки через мости Тільки через мости Тільки через мости
Схожі мови (для формування корпоративного стандарту) MS Visual Basic, any Basic JavaScript, Java, C, C++ Perl, PHP
Проект може мігрувати на іншу Web-технологію Ні Так, на JSP Так, на PHP або Perl CGI / ISAPI
Проект може мігрувати на іншу платформу Ні Так, JSP на будь-який JSP-сумісної платформі Так, PHP / Perl на будь-який PHP / Perl-сумісної платформі

Критеріями вибору скрипта розробки для ASP можуть стати:



У світлі вищеописаних критеріїв, можна порекомендувати вибір на користь JScript.


Загальна об'єктно-орієнтована бібліотека: 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 можна навантажити дрібними функціями – контролем усіляких пулів та кешей, перевіркою валідності об'єкта і т.д. І, щоб уже зовсім по-модному, доступ до вищеописаних об'єктів повинен здійснюватися через єдиний об'єкт-ядро:


Core – Цей об'єкт повинен бути присутнім у всіх ASP сторінках основного коду в єдиному екземплярі (синглетонами також повинні бути об'єкти Config, ConfigUser і ObjectFactory. А от DB-об'єкти – необов'язково). Головне завдання об'єкта Core – створювати і повертати всі описані вище об'єкти написаної вами бібліотеки, гордо іменується Project ASP API. Наприклад, Core.getConfigApp () створить об'єкт ConfigApp і поверне на нього посилання. Повторний виклик не буде створювати об'єкт повторно, а поверне те ж посилання (щоб гарантувати, що ConfigApp залишиться синглетонами). Крім того, що основною ASP-код стане більш зрозумілим, ми одержимо дуже корисний ефект. Core може запам'ятовувати посилання на всі створені ним об'єкти. І викликавши в кінці ASP-сторінки метод, наприклад, Core.close (), ми отримаємо гарантоване закриття всіх об'єктів, навіть якщо ми забули закрити їх в основному коді. Для об'єктів роботи з базою даних це особливо критично.


Звичайно, стандартним повинен бути і об'єкт для роботи з джерелом даних, але про нього пізніше.

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*