Разработка структуры вэб-представительства

Введение

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

Для того чтобы конечные пользователи могли пользоваться полученной информацией, требуются единые протоколы её кодирования и передачи. Их существует великое множество, одним из основных является предложенный в 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 Структура базы данных

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

В основе процесса создания базы данных лежат определенные принципы. Первый принцип заключается в необходимости исключать повторяющиеся (или лишние) данные, т. к. они занимают место и повышают вероятность возникновения ошибок и неполадок. Второй принцип касается важной роли правильных и полных данных. Если база данных содержит неправильные данные, все отчеты, в которых данные объединяются, будут также содержать неверные сведения. Это может привести к принятию неправильных решений на основе отчетов.

Правильная структура базы данных подразумевает:

- распределение данных по тематическим таблицам в целях сокращения объема повторяющихся данных;

- добавление данных, необходимых для объединения сведений, которые содержатся в таблицах;

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

Процесс разработки

Процесс разработки базы данных включает следующие шаги.

- Определение цели создания базы данных

Это позволяет подготовиться к выполнению следующих шагов.

- Поиск и организация необходимых данных

Следует собирать все данные, которые необходимо сохранить в базе данных - Распределение данных по таблицам

Требуется распределить элементы данных по группам или темам. Для каждой темы будет создана таблица.

- Преобразование элементов данных в столбцы

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

- Задание первичных ключей

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

- Создание связей между таблицами

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

- Усовершенствование структуры

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

- Применение правил нормализации

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

Ниже представлена структура базы данных для ГОУ СОШ №1194



2. Технологический раздел

2.1 Проектирование на языке UML

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

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

С повсеместным распространением ООП проектировщики всё чаще стали обращаться к понятию «класс» как к универсальной единице структуры программы и как к актеру поведения. Одновременно несколько видных исследователей - Буч, Джекобсон, Румбах и другие - начали разрабатывать концепции языков, которые могли бы описать все аспекты работы программы, и были бы столь же эффективными, как языки программирования. Их работа вылилась в принятый консорциумом OMG стандарт Unified Modeling Language, который на сегодняшний день используется множеством разработчиков по всему миру и продолжает совершенствоваться.

2.1.1 Концепция Unified Modeling Language

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

1) абстрагирование - в модель включаются только те аспекты проектируемой системы, которые имеют непосредственное отношение к выполнению системой описываемых функций;

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

3) иерархическое построение - модель строится на разных уровнях абстракции в зависимости от необходимости раскрытия деталей на данном этапе проектирования.

UML предназначен для описания двух основных видов моделей: статических (модели, описывающие структуру) и динамических (модели, описывающие поведение). Нотация UML, как языка визуального проектирования, включает в себя большое количество компонентов графической нотации. Основными понятиями UML являются «класс», «атрибут», «операция» и «отношение». Основное представление понятий - диаграмма.

2.1.2 Виды диаграмм UML

Диаграммы UML, как и было сказано выше, являются основным способом представления моделей. Последовательность рассмотрения диаграмм в данном подразделе обусловлена рекомендациями Rational Unified Process и наглядно показывает последовательность моделирования системы.

Диаграмма прецедентов (use case diagram)

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

Каждый прецедент характеризует некую предполагаемую последовательность действий. Актер представляет некую внешнюю по отношению к модели сущность. Существует несколько стандартных видов отношений между актерами и прецедентами:

1) ассоциация - указание на семантическую связь актера и прецедента (например, актер инициирует прецедент);

2) включение - указание на то, что заданное поведение одного прецедента включается как составная часть в поведение другого;

3) расширение - указание на то, что заданное поведение прецедента может использоваться другим в случае выполнения неких условий;

4) обобщение - указание на то, что прецедент или актер является специальным случаем другого прецедента или актера соответственно.

Диаграмма классов (class diagram)

Диаграмма классов служит для представления статической структуры модели системы в терминологии классов объектно-ориентированного программирования. В общем случае такая диаграмма представляет собой конечный граф, вершинами которого являются элементы типа «классификатор», а ребрами - некие типы структурных отношений. Элементы диаграммы классов в совокупности отражают декларативные знания о предметной области. Эти знания интерпретируются в базовых понятиях UML, таких как классы, интерфейсы и отношения между ними и их составляющими. При этом отдельные элементы диаграммы могут объединяться в пакеты для представления более общей модели системы.

Класс в UML является абстрактным описанием свойств множества объектов, обладающих одинаковой структурой, поведением и отношениями с объектами других классов. Класс обладает набором атрибутов или свойств, а также набором операций или методов. Выделяется понятие шаблонного класса, аналогичное одноименному из языка С++.

Между классами могут быть следующие отношения:

1) ассоциация - произвольная семантическая связь классов, может иметь кратность (аналогично ER-диаграммам);

2) обобщение - отношение между предком и потомком, интерпретация наследования;

3) агрегация - включение одной сущностью других как составных частей, взаимосвязь между частью и целым;

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

5) зависимость - семантическая связь, не являющаяся какой-либо из вышеперечисленных.

Интерфейс в UML - это специальный случай класса, когда специфицируется только его поведение.

Диаграмма кооперации (collaboration diagram)

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

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

Диаграмма последовательности (sequence diagram)

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

Диаграмма состояний (statechart diagram)

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

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

Диаграмма деятельности (activity diagram)

Диаграмма деятельности является самым низкоуровневым видом диаграмм UML. Её семантика сродни многократно стандартизованным правилам записи блок-схем алгоритмов.

Диаграмма компонентов (component diagram)

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

Диаграмма развертывания (deployment diagram)

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

2.1.3 Связь с объектно-ориентированными языками

Некоторые виды диаграмм UML, например диаграммы классов, очень хорошо поддаются обработке генераторами кода. Соответствующие инструментальные средства встроены в большинство мощных CASE-средств, таких как, например, Rational Rose. По данным диаграммы классов такое инструментальное средство способно создать набор файлов со сгенерированными определениями классов, включая их свойства и методы согласно спецификациям диаграммы.

2.2 Архитектура Microsoft.NET Framework 2.0

NET Framework включает в себя среду времени выполнения программ, называемую общеязыковой средой выполнения (common language runtime), которая управляет исполнением кода и обеспечивает сервисами, которые упрощают процесс разработки. Компиляторы и утилиты расширяют функциональность среды выполнения, и позволяют вам писать код, который будет пользоваться всеми преимуществами среды. Код, который создан компилятором языка, для среды выполнения, называется управляемым кодом, он получает такие возможности, как межъязыковая интеграция, межъязыковая обработка исключений, расширенные возможности по безопасности, поддержки версионности и развертывания, упрощенная модель взаимодействия компонент, сервисы для отладки и профилирования.

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

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

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

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

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