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

Для того чтобы конечные пользователи могли пользоваться полученной информацией, требуются единые протоколы её кодирования и передачи. Их существует великое множество, одним из основных является предложенный в 1991 году протокол HTTP (протокол передачи гипертекста), изначально призванный для передачи в простой текстовой форме графического оформления текстов и соединения различных документов при помощи гиперссылок.

Со временем Интернет перестал быть только средой для передачи текстовой информации. Страницы становились всё более красочными и, что самое важное, интерактивными. Пользователь стал не просто читать текст, переходя по гиперссылкам, а взаимодействовать с сайтом, как с прикладной программой, посылая запросы на сервер и ожидая определённой реакции. Протокол HTTP совершенствовался, страницы становились больше в объёме и требовали значительной загрузки сервера, который теперь не просто отдавал статическое содержимое, а генерировал страницы в соответствии с запросами пользователя и содержимым используемых баз данных.

В сети стремительно развивается коммерция, реклама, игровой бизнес. Своими сайтами обзаводятся образовательные учреждения, научные и медицинские центры, правительственные структуры. Сейчас работа ни одной более-менее серьёзной компании не обходится без постоянного контакта с Интернетом. Что стоит за всем этим?

Как и всегда, за внешней красотой и лёгкостью использования скрывается огромный труд тысяч людей - программистов. Программистов, потому что для создания современных веб-приложений недостаточно овладеть искусством вёрстки HTML и иметь художественный вкус, поскольку всё это не заменит навыков работы с базами данных и, что более важно в крупных проектах, понимания верной архитектуры веб-ориентированного приложения.

Задача программирования состоит не только в решении конкретной задачи, но и в учёте возможности масштабирования, переносимости и доработки программного обеспечения. Исходя из этого, задача среды программирования - это в свою очередь не просто дать возможность программисту набрать нужный код, а как можно более облегчить ему эту задачу, при этом не сузив возможности. Правильный выбор среды программирования может облегчить дело и уменьшить сроки разработки в разы, при этом нисколько не ухудшив функционал и внешний вид приложения.

Однако даже при работе в самой продуманной и удобной среде возникает масса нюансов, связанных с реализацией. При создании веб-представительства была поставлена задача не только разработки конкретного программного продукта, но и построения продуманной архитектуры, позволяющей лёгкую модификацию, расширение и добавление новых компонентов. Выполнение этой задачи было связано с изучением и использованием паттернов объектно-ориентированного проектирования, ORM-технологии NHibernate и некоторых других технологий и приёмов проектирования.

В целом можно выделить следующие задачи, вставшие передо мной в процессе создания веб-представительства:

· исследование предметной области;

· принятие решений, позволяющих создание легко расширяемой и изменяемой структуры веб-представительства;

· разработка схем данных;

· разработка алгоритмов работы;

· программная реализация веб-интерфейса;

· программная реализация административной подсистемы, позволяющей осуществлять управление ресурсами веб-представительства;

· отладка и тестирование;

· запуск веб-представительства в работу.

1. Специальный раздел

1.1 Исследовательская часть

1.1.1 Постановка задачи

В начале разработки жёстких требований к функционалу веб-представительства не выдвигалось, были только рекомендации по контенту.

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

1. Создание веб-интерфейса для отображения статического контента (основная задача - обеспечить как можно более одинаковое отображение сайта в различных браузерах, о чём речь пойдёт ниже).

2. Создание базы данных для хранения динамического контента, такого как списки занятий, учителей и т.п. База данных была построена на MSSQL Server 2005, но для.NET вообще говоря это не имеет ключевого значения - мы можем хранить данные практически в любой СУБД.

3. Создание инструментария для воспроизведения динамического контента на страницах сайта. Здесь вполне современным подходом явилось использование ORM-модели NHibernate. Это несколько избыточно в рамках небольшого проекта, однако как будет продемонстрировано ниже, важно в смысле расширяемости БД и централизации кода.

4. Создание административной подсистемы, которая должна позволять работать с базой данных, изменяя, добавляя и удаляя записи таблиц, а также управлять сайтом.

Актуальность задачи.

К моменту написания работы повсеместный выход образовательных учреждений в интернет является общей тенденцией. В свете этого создание полнофункционального веб-представительства является актуальной задачей.

Большинство школ использует готовые движки, не приспособленные под нужды образовательных учреждений. Разрабатываемая структура веб-представительства должна обеспечить возможности лёгкого изменения для каждого конкретного образовательного учреждения, её компоненты должны быть легко настраиваемыми, заменяемыми и расширяемыми.

1.1.2 Требования, предъявляемые к веб-представительству

На сайте должно быть размещено содержимое двух видов:

а) статическое, не зависящее от содержимого базы данных, в том числе:

- история школы;

- герб и флаг школы;

- общая информация о школе;

- информация о работе со школьниками;

- информация о работе с дошкольниками;

- устав школы;

- публичный доклад.

б) динамическое, отражающее состояние базы данных

- фотогалерея;

- некоторые факты о школе;

- расписание;

- локальные акты;

- новости школы;

- гостевая книга.

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

Дизайн должен быть не слишком броским и достаточно функциональным. Официальный сайт образовательного учреждения - не место для особых изысков.

1.1.3 Потребности пользователей и администраторов

Самое главное, что необходимо помнить, говоря о потребностях пользователей системы, это то, что на различных компьютерах могут быть установлены различные интернет-браузеры.

Работая над оформлением страницы, вы должны учитывать различия аппаратного и программного обеспечения, используемого разными пользователями. Ваше творение может по-разному выглядеть на разных мониторах с разными режимами. Свое влияние может оказать операционная система, но наиболее важным фактором, влияющим на вид страницы, является используемый пользователем браузер. Разрабатываемые разными фирмами программы для просмотра web-страниц обладают разными возможностями и набором функций. Возникает ситуация, в которой браузер пользователя окажется не в состоянии правильно воспроизвести все ваши идеи.

Различия между браузерами проявляются прежде всего в наборах обрабатываемых тегов - команд HTML. Существует набор тегов, стандартизированный консорциумом WWW (W3) - организацией, контролирующей развитие Всемирной Паутины. Разработчики программного обеспечения в принципе должны следовать рекомендациям и стандартам консорциума - это необходимо для поддержания преемственности и совместимости программ и систем разных поколений. Но не всем удается точно выполнить все, что требует стандарт. Некоторые наоборот, стремятся внести в HTML что-либо свое - новые теги, параметры, функции. Иногда такие нововведения принимаются другими производителями и становятся стандартом, иногда они остаются свойствами конкретной программы. Такие различия приводят к тому, что возможности браузеров даже в воспроизведении стандартных тегов могут значительно различаться. Это создает большие проблемы для дизайнеров и web-программистов - им приходится при разработке страницы учитывать возможности и характеристики всех браузеров, которые могут оказаться у потенциального пользователя. Так как учесть все существующие программы невозможно, я ориентировался на самые распространённые браузеры: Microsoft Internet Explorer 6.0, поставляемый с операционной системой Windows XP, Microsoft Internet Explorer 7.0, поставляемый c операционной системой Windows Vista (возможна установка на Windows XP) и на Mozilla Firefox v2.1, Opera и Google Chrome.

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

Эти требования обязательно должны быть учтены.

Потребности администраторов - это как можно более комфортная, быстрая и безопасная работа с базой данных.

В этих целях предполагается разработать отдельное десктопное приложение, позволяющее редактировать данные базы безотносительно к сайту.

Таким образом, никто из имеющих доступа на сайт пользователей не сможет никаким образом изменить или удалить содержимое базы данных, а также повышается скорость работы и уменьшается интернет-трафик.

Единственным минусом этого подхода является необходимость наличия на компьютере администратора (контент-менеджера) сайта самой программы-административной подсистемы.

1.1.4 Выводы

Исследовав предстоящую задачу, можно сделать выводы относительно шагов её решения и составить план действий по их осуществлению.

1. Необходимо выбрать среду разработки и платформу для размещения приложения.

2. Необходимо спланировать архитектуру веб-приложения.

3. Требуется принять дизайнерские решения.

4. Начать разработку сайта, основываясь на принятых решениях и на информации о необходимом содержимом.

5. Продолжать разработку, учитывая динамический контент.

6. При этом не забывать постоянно проверять работу сайта в разных браузерах и при различных разрешениях монитора.

7. Разработать основу административной подсистемы, позволяющую легко переключать её на редактирование отдельных таблиц БД.

8. Создать редакторы для изменения, удаления и сохранения новых записей. Учесть, что многие записи взаимосвязаны и имеют определённые ограничения.

9. Тестировать работу административной подсистемы и сайта.

9. Запустить сайт в работу.

1.2 Конструкторская часть

1.2.1 Структура входных и выходных данных

Работа с сайтом осуществляется по ставшему стандартом для Internet протоколу HTTP.

HTTP (HyperText Transfer Protocol - протокол передачи гипертекста) был разработан как основа World Wide Web.

Работа по протоколу HTTP происходит следующим образом: программа-клиент устанавливает TCP-соединение с сервером (стандартный номер порта-80) и выдает ему HTTP-запрос. Сервер обрабатывает этот запрос и выдает HTTP-ответ клиенту.

Структура HTTP-запроса

HTTP-запрос состоит из заголовка запроса и тела запроса, разделенных пустой строкой. Тело запроса может отсутствовать.

Заголовок запроса состоит из главной (первой) строки запроса и последующих строк, уточняющих запрос в главной строке. Последующие строки также могут отсутствовать.

Запрос в главной строке состоит из трех частей, разделенных пробелами:

Метод (иначе говоря, команда HTTP):

GET - запрос документа. Наиболее часто употребляемый метод; в HTTP/0.9, говорят, он был единственным.

HEAD - запрос заголовка документа. Отличается от GET тем, что выдается только заголовок запроса с информацией о документе. Сам документ не выдается.

POST - этот метод применяется для передачи данных CGI-скриптам. Сами данные следуют в последующих строках запроса в виде параметров.

PUT - разместить документ на сервере. Насколько я знаю, используется редко. Запрос с этим методом имеет тело, в котором передается сам документ.

Ресурс - это путь к определенному файлу на сервере, который клиент хочет получить (или разместить - для метода PUT). Если ресурс - просто какой-либо файл для считывания, сервер должен по этому запросу выдать его в теле ответа. Если же это путь к какому-либо CGI-скрипту, то сервер запускает скрипт и возвращает результат его выполнения. Кстати, благодаря такой унификации ресурсов для клиента практически безразлично, что он представляет собой на сервере.

Версия протокола - версия протокола HTTP, с которой работает клиентская программа.

Таким образом, простейший HTTP-запрос может выглядеть следующим образом:

GET / HTTP/1.0

Здесь запрашивается корневой файл из корневой директории web-сервера.

Строки после главной строки запроса имеют следующий формат:

Параметр: значениe.

Таким образом задаются параметры запроса. Это является необязательным, все строки после главной строки запроса могут отсутствовать; в этом случае сервер принимает их значение по умолчанию или по результатам предыдущего запроса (при работе в режиме Keep-Alive).

Перечислю некоторые наиболее употребительные параметры HTTP-запроса:

Connection (соединение) - может принимать значения Keep-Alive и close. Keep-Alive («оставить в живых») означает, что после выдачи данного документа соединение с сервером не разрывается, и можно выдавать еще запросы. Большинство браузеров работают именно в режиме Keep-Alive, так как он позволяет за одно соединение с сервером «скачать» html-страницу и рисунки к ней. Будучи однажды установленным, режим Keep-Alive сохраняется до первой ошибки или до явного указания в очередном запросе Connection: close.

close («закрыть») - соединение закрывается после ответа на данный запрос.

User-Agent - значением является «кодовое обозначение» браузера, например:

Mozilla/4.0 (compatible; MSIE 5.0; Windows 95; DigExt)

Accept - список поддерживаемых браузером типов содержимого в порядке их предпочтения данным браузером, например для моего IE5:

Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-excel, application/msword, application/vnd.ms-powerpoint, */*

Это, очевидно, нужно для случая, когда сервер может выдавать один и тот же документ в разных форматах.

Значение этого параметра используется в основном CGI-скриптами для формирования ответа, адаптированного для данного браузера.

Referer - URL, с которого перешли на этот ресурс.

Host - имя хоста, с которого запрашивается ресурс. Полезно, если на сервере имеется несколько виртуальных серверов под одним IP-адресом. В этом случае имя виртуального сервера определяется по этому полю.

Accept-Language - поддерживаемый язык. Имеет значение для сервера, который может выдавать один и тот же документ в разных языковых версиях.

Формат HTTP-ответа

Формат ответа очень похож на формат запроса: он также имеет заголовок и тело, разделенное пустой строкой.

Заголовок также состоит из основной строки и строк параметров, но формат основной строки отличается от таковой в заголовке запроса.

Основная строка запроса состоит из 3-х полей, разделенных пробелами:

Версия протокола - аналогичен соответствующему параметру запроса.

Код ошибки - кодовое обозначение «успешности» выполнения запроса. Код 200 означает «все нормально» (OK).

Словесное описание ошибки - «расшифровка» предыдущего кода. Например для 200 это OK, для 500 - Internal Server Error.

Наиболее употребительные параметры http-ответа:

Connection - аналогичен соответствующему параметру запроса.

Если сервер не поддерживает Keep-Alive (есть и такие), то значение Connection в ответе всегда close.

В зависимости от значения Content-Type браузер воспринимает ответ как HTML-страницу, картинку gif или jpeg, как файл, который надо сохранить на диске, или как что-либо еще и предпринимает соответствующие действия. Значение Content-Type для браузера аналогично значению расширения файла для Windows.

Некоторые типы содержимого:

text/html - текст в формате HTML (веб-страница);

text/plain - простой текст (аналогичен «блокнотовскому»);

image/jpeg - картинка в формате JPEG;

image/gif - то же, в формате GIF;

application/octet-stream - поток «октетов» (т.е. просто байт) для записи на диск.

На самом деле типов содержимого гораздо больше.

Content-Length («длина содержимого») - длина содержимого ответа в байтах.

Last-Modified («Модифицирован в последний раз») - дата последнего изменения документа.

Прямая работа с HTTP не является необходимостью в рамках задачи по построению сайта, однако необходимо знать основы работы с этим протоколом.

Работа с административной подсистемой заключается только в обращении администратора к пользовательскому интерфейсу. Соединения с базой данных являются стандартными.NET-компонентами и не требуют вмешательства извне.

Все производимые администратором изменения должны немедленно отображаться, что также является задачей пользовательского интерфейса.

1.2.2 Выбор платформы проектирования и его обоснование

В качестве языка разработки для веб-представительства был выбран C# и технология Microsoft ASP.NET 2.0. На это повлияло несколько факторов, решающими из которых явились:

- наличие большого опыта работы с.NET-технологиями;

- возможность написания одних компонентов доступа как для веб-приложения, так и для административной подсистемы;

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

Прочие преимущества ASP.NET 2.0, применяемые в работе, можно увидеть на рисунке.

Таблица 1. Выбор платформы проектирования

В качестве платформы проектирования была выбрана MS Visual Studio 2005, позволяющая полностью реализовать все возможности технологии и распространяемая бесплатно для студентов ВУЗов.

Ниже приводится подробный список основных технологий, использованных при работе над сайтом с обоснованием их выбора.

1. Язык высокого уровня Microsoft C# 2.0

Это - основа приложений на.NET. Впрочем, этой основой может быть и любой другой язык, для которого существует.NET-совместимый компилятор. Преимущества С# очевидны (и, надо сказать, во многом заимствованы из Java)

1) Абсолютная объектная ориентированность. Любая сущность является объектом, будь то целочисленная переменная или объект класса. Полную объектную ориентированность можно считать не только плюсом, а единственным вариантом структуры достаточно сложной системы. Мышление человека (программиста) оперирует объектами, и действие без производящего его объекта, каковым является в описании, скажем, на С, отдельная функция, является вещью труднопонимаемой, с чем приходится сталкиваться в процессе изучения этого языка программирования.

2) Наличие готовых библиотек классов. Всем приходилось писать связные списки, все придумывали свои классы для работы со строками и файлами. Каждый программист, на чью долю выпадала эта задача, знает, что в итоге исходные коды «хороших» классов перетягиваются из проекта в проект и прочно приживаются в них так же, как и разные <stdlib> и <vector> из стандартного набора С++. Одной из причин успеха.NET и послужило то, что нам более нет необходимости продумывать детали работы таких вспомогательных и часто используемых классов. Библиотека, идущая вместе с.NET Framework, предоставляет стандартные классы для работы с коллекциями, строками, файлами и т.п. Опять же, мы думаем над тем, что именно пишем, а не как это делаем, откуда имеем повышение производительности и надёжности.

3) Отсутствие неясностей. Указатели, явное выделение, и, главное, освобождение памяти, конструкторы копирования, множественное наследование, ссылочная передача параметров, различные cast-ы затемняют язык и заставляют программиста думать на более низком уровне

С++ - отличный язык, позволяющий освоить системное программирование и понять многие вещи, но это не лучший выбор именно для написания надёжных приложений. В С# убрано большинство спецсимволов и многие вещи стандартизированы так, что даже не зная точно, по логике языка можно догадаться, как всё должно работать. Это основные, но вполне весомые доводы за С#.

2. ASP.NET 2.0

Преимуществами ASP.NЕT 2.0 являются объектная модель страницы, позволяющая реализацию таких паттернов как MVP, наличие удобной среды разработки и большого числа готовых компонентов.

3. NHibernate

ORM (Object-relational mapping) - отображение структуры базы данных на набор связанных объектов в приложении. Дело в том, что смесь кода на языке высокого уровня с SQL-вставками, плохо читается, не говоря уже о возможностях SQL-инъекций и появлению «magic numbers».

Тот, кто работал с базами данных в Java, наверняка слышал о Hibernate. Так вот, NHibernate - это порт Hibernate на.NET. Это не разработка Microsoft, которая сейчас активно двигает LINQ, а бесплатный продукт. NHibernate посвящена отдельная глава.

4. JavaScript

Никому не хочется ждать, пока страница отправится на сервер только для того, чтобы содержимое текстового поля заполнилось содержимым другого элемента управления. Всем хочется видеть анимацию, а не статичные картинки на сайте. Для всего этого и предназначен JavaScript, ставший стандартом для осуществления клиентской логики веб-приложения.

Чтобы оценить важность клиентских сценариев, можно просто отключить их в браузере и попробовать походить по Интернету. Как можно будет скоро убедиться, JavaScript работает практически на каждой странице и его цель - не только отображать посередь экрана рекламные ролики, но и, как изначально задумывалось, ускорить работу пользователя и сделать её более интересной.

Проблема сценариев - в сложности их написания. JavaScript в плане объектной реализации оставляет желать лучшего, а так как он ещё и нетипизирован, то приходится или помнить все свойства объектов, или лазить каждый раз в Интернет, так как autocomplete отсутствует.

К счастью, разработчики ASP.NET подумали о разработчиках, которые просто хотят что-то сделать, при этом затратив меньше времени и получив максимум отдачи.

В итоге каждый элемент управления ASP.NET, имеющий клиентское поведение, уже реализует это поведение и кроме некоторых исключений, нам вовсе не надо писать его руками, а достаточно задать декларативно. Так что JavaScript в ASP.NET носит скорее вспомогательный характер (впрочем, серьёзные приложения не обходятся без рукописных сценариев).

5. AJAX - Asynchronious JavaScript and XML

Нашумевшая технология AJAX сейчас используется повсеместно. Не неся ничего по сути нового с точки зрения именно технологий, она значительно повышает производительность и красоту сайта для глаза конечного пользователя. При помощи JavaScript на сервер отправляется запрос в формате XML, в формате же XML приходит ответ и JavaScript обновляет только нужную часть страницы, экономя трафик и избавляя от ожидания перезагрузки страницы.

В ASP.NET существует своя версия AJAX, построенная на встраиваемых в страницу элементах управления и очень простая в использовании.

6. BB-code

Во многих текстах есть смысл что-то выделить, что-то подчеркнуть и так далее. Удобным средством для этого является bb-code, позволяющий при помощи простых тегов, напоминающих HTML-разметку, без труда указать текст, подлежащий выделению. На сайте используется один из бесплатных.NET bb-code-парсеров.

7. MSSQL Server 2005 + T-SQL

Одним из наиболее изменяемых языков является язык запросов к СУБД SQL. Модификация для майкрософтовских серверов Transact-SQL обладает многим из того, чего очень хотелось, но не хватало раньше.

Язык включает в себя переменные, в том числе как скалярные, так и табличные, условные операторы, операторы циклов, возможность внутри SQL генерировать и исполнять другие SQL-команды и многое другое. Хотя в свете использования ORM это и не так уж важно, но всё же T-SQL - это значительный шаг вперёд.

Плюс ко всему исключительно удобным является инструментарий, который может быть использован при разработке с учётом этих технологий. По сути, нам требуется MS Visual Studio 2005, SQL Server Management Studio 2005, и… всё, если не считать Windows с предустановленным браузером. (Конечно, я ставил несколько браузеров для теста внешнего облика и работы сайта).

Принципы работы ASP.NET

Любой инструмент программирования - это не только набор правил и строк кода. В любой технологии заключено то зерно рациональности и смысла, которое делает её чем-то большим, нежели просто языком или способом разметки.

Никто не скажет, что знает, допустим, английский язык, если выучит словарь языка. Также нельзя говорить о полном владении технологии, если просто представляешь, как что-то написать, лишь бы работало.

ASP.NET 2.0 - мощный инструмент, выполненный логично и разумно. И для рационального использования его, как и практически каждого инструмента программирования, неплохо понимать, как он работает. И, кроме того, как предполагается с ним работать. Потому что как и каждый мощный язык, C# допускает вольности, но это не значит, что их нужно использовать к месту и не к месту.

Итак, обратимся к основным принципам ASP.NET 2.0. Чтобы не отходить от задач работы, сделаю на примере моего сайта.

Первое и главное - это извечное «разделяй и властвуй». Если код на разных языках находится в одном файле (т.н. спагетти-код), это может означать неудачный выбор инструмента, или неумение им пользоваться (разумные исключения, конечно, приветствуются, нет смысла из-за двух строк на JavaScript заводить отдельный js-файл).

В ASP.NET этот принцип реализован целиком и полностью. Весь код, который выполняется на сервере, лежит в отдельном от разметки страницы файле, именуемом codebehind-файлом. Этот код может быть написан на любом языке, более того, в одном проекте могут быть codebehind-файлы на разных.NET-совместимых языках (но это, вообще говоря, крайности).

Класс страницы, описанный в codebehind-файле, реагирует на определённые события, таким как запрос страницы с сервера, загрузка её, рендеринг содержимого, нажатия кнопок и т.п. Всё, что требуется - это написать в обработчиках этих событий нужный код на любимом языке. Это не просто удобно, это эстетично. И самое главное - это читается! Программист, сопровождающий код, не должен будет сталкиваться со смесью разметки и кода (Вспомнилась цитата про PHP-программиста, который в одном файле писал на шести языках: русском, английском, PHP, HTML, JavaScript и SQL. При использовании ASP.NET это не грозит.

Второе - это объектная ориентированность. Все страницы являются объектами своих классов. Важно, что элементы управления (кнопки, списки и т.п.) тоже являются объектами, и работа с ними соответственно упрощается. Серверному коду неинтересно, как они визуализируются браузером - каждый элемент управления уже умеет себя «рисовать»!

Третье - это компромисс между браузерами. Всем, кто работал с веб, известно, что компании-производители тянут одеяло на себя и разные браузеры воспроизводят одинаковую разметку по-разному. Элементы управления ASP.NET умеют генерировать различный код дл различных браузеров. А для создаваемых вами элементов существует возможность задать, допустим, две ширины, для браузеров ie и для браузеров mozilla.

Дальше идёт такая немаловажная вещь, как единообразие облика сайта. В лучших традициях объектно-ориентированного программирования дизайн страниц теперь наследуем и создав одну так называемую мастер-страницу, на остальных можно описывать только конкретные элементы, специфичные для данного раздела. Это достигается посредством размещения тегов <ContentPlaceHolder> на мастер-странице и <Content> на наследниках.

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

Более глубокий объектно-ориентированный подход, применяемый мной на сайте, использует модель MVP (Model-View-Presenter), которая позволяет ещё сильнее разделить логику приложения. При обзоре взаимодействия компонентов на это будет обращено внимание.

1.2.3 Проектирование архитектуры сайта

Начнём рассмотрение с самого верхнего уровня и будем спускаться ниже, изучая структуру сайта.

На самом верхнем уровне лежит классическая модель клиент-сервер-БД, к которой добавлено несколько промежуточных уровней.

Как видно из схемы, клиент взаимодействует с сервером ASP.NET через веб-сервер (IIS), который выполняет запросы к базе через подсистему NHibernate. Рассмотрим реализацию данной структуры более детально.

Веб-интерфейс состоит из пяти проектов, каждому из которых отведена строго определённая роль.

1) Admin - проект, содержащий Windows-приложение - административную подсистему, служащую для управления содержимым базы данных.

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

3) Core - проект, посвящённый объектной модели NHibernate и интерфейсам доступа к данным.

4) Data - проект содержит фабрику классов NHibernate и классы доступа к данным, реализующие интерфейсы из Core.

5) Собственно веб-сайт.

Для того чтобы понять роль, отведённую основным классам проекта, необходимо обратиться к модели MVP (Model-View-Presenter), отлично ложащейся на веб-приложение.

Смысл её в отделении Модели (в данном случае это размеченные классы под управлением NHibernate) от Представления (это классы, стоящие за codebehind-классами страниц и не знающие о них ничего, кроме интерфейсов) и от Вида - собственно codebehind-классов страниц, которые таким образом лишаются бизнес-логики, вынесенной в Представления и отвечают только за внешний вид страницы.

Для того чтобы связать всё это воедино, служит базовый класс страницы BasePage из BL:

public abstract class BasePage<TPresenter, TView>: Page, IView

where TPresenter: IPresenter<TView>, new()

where TView: IView

{

// ………

}

Будучи параметризованным, этот класс снабжается типом своего конкретного Представления и типом интерфейса Вида, который нужен для создания Представления.

Также класс содержит общие для всех страниц методы, что экономит код и в принципе является назначением базового класса.

Помимо паттерна проектирования MVP одним из наиболее часто используемых паттернов является Singleton - паттерн, позволяющий иметь не более одного объекта заданного класса. Очень часто ограничения логики требуют явного указания того, что объект единственен в своём роде, как, например, колода карт в карточной игре.

Параметризованный класс Singleton из BL позволяет «на лету» делать одиночку из любого класса, не внося в него изменения.

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

Диаграмма классов сборки BL (часть классов Представлений опущена).

(

Сборка Core содержит по одному интерфейсу на каждый объект модели DAO системы. Все интерфейсы произведены от базового интерфейса IDao, что позволяет экономить на их реализации. Пример интерфейса:

public interface IDisciplineDao: IDao<Discipline, int>

{

}

Как можно видеть, интерфейс для получения данных о дисциплинах из базы данных не содержит никаких методов, дополнительных к методам IDao. Однако для логически правильной объектной модели он необходим, к тому же если нам понадобится добавить, например, метод для извлечения только определённых дисциплин по какому-либо критерию, мы легко можем сделать это.

Базовый интерфейс IDao даёт доступ к основным методам извлечения объектов из базы и записи в неё безотносительно к конкретному типу объекта.

public interface IDao<T, IdT>

{

T GetById (IdT id, bool shouldLock);

T GetFirst();

List<T> GetAll();

List<T> GetAllSorted (params Order[] orders);

List<T> GetAllSorted (string propertyName, bool isAsc);

List<T> GetByExample (T exampleInstance, params string[] propertiesToExclude);

T Save (T entity);

T SaveOrUpdate (T entity);

void Delete (T entity);

void CommitChanges();

}

Интерфейс IDaoFactory даёт доступ к методам фабрики классов - ещё один используемый паттерн проектирования, - которые возвращают интерфейс объектов DAO.

Ниже приводится диаграмма классов сборки Core.

Сборка Data - это сердце управляющей системы NHibernate. Именно здесь расположены классы, отвечающие за установление соединения с базой и его поддержание, здесь же хранятся сами объекты DAO, предназначенные для извлечения данных из БД и за их размещение и изменение.

Ниже приведена диаграмма классов сборки Data. Обратите внимание, как здесь органично находят применение интерфейсы из сборки Core. По идее из внешних сборок мы не должны видеть пространства имён и классы сборки Data, обращаясь к ней только через интерфейсы, описанные в Core.

Архитектура самого сайта как веб-ориентированного приложения основывается на философии ASP.NET 2.0 (см. главу 2.3) и на описанных в главе 2.1 паттернах проектирования.

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

Также имеются папки:

- UI (User Interface) - папка, содержащая файлы разметки страниц и codebehind, а также css-файл со стилями и мастер-страницу, служащую для единообразного оформления (см. главу 2.3)

- Resources - разнообразные ресурсы приложения, как доступные для скачивания.doc и другие файлы, так и изображения, используемые на сайте, а также справка по использования bb-code и конфигуратор bb-code дешифратора.

1.2.4 Алгоритмы работы административной подсистемы

В этом разделе рассматривается не взаимодействие с пользователем (см. 1.2.2.), а принципы построения системы, позволяющие сделать её гибкой и настраиваемой.

Основным классом, отвечающим за пользовательский интерфейс приложения, является класс EditorFrame, представляющий собой Windows-форму и параметризованный типом конкретного редактора.

При создании объекта EditorFrame ему передаётся тип редактора (должен быть производным от базового типа BaseItemEditControl, который в свою очередь унаследован от UserControl), объект которого создаётся в конструкторе и встраивается в окно фрейма.

Таким образом, после того как пользователь выберет тип редактируемой таблицы (группы таблиц) он получает сгенерированное окно с нужным редактором. Всё это возможно благодаря единообразию модели NHibernate DAO и системе.NET Reflection, которые вместе позволяют использовать неизвестные заранее классы, определяемые во время выполнения.

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

1.2.5 Структура базы данных

Страницы: 1, 2