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

БОЛЬШАЯ ЛЕНИНГРАДСКАЯ БИБЛИОТЕКА - РЕФЕРАТЫ - Разработка структуры вэб-представительства

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

Введение

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

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

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

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

- более высокая производительность.

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

- расширяемые типы, поддерживаемые библиотекой классов.

- широкое множество языковых возможностей.

- межъязыковая интеграция, особенно межъязыковое наследование.

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

- самоописывающиеся объекты, которые делают ненужным использование Interface Definition Language (IDL).

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

2.3 Архитектура ASP.NET 2.0

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

1) Взаимодействие с IIS

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

При использовании IIS 5, среда выполнения ASP.NET представлена отдельным процессом aspnet_wp.exe. Этот процесс получает управление от IIS с помощью ASP.NET ISAPI расширения aspnet_isapi.dll. Если расширение запрошенного ресурса связано с ASP.NET ISAPI расширением, то запрос поступает на обработку рабочим процессом ASP.NET, который, в свою очередь, отвечает за загрузку CLR, создание управляемых объектов и выстраивания очереди событий для ASP.NET страницы. В этом случае особенно важно отметить, что рабочий процесс aspnet_wp.exe обслуживает все веб-приложения: каждое приложение выполняется в отдельном домене приложения AppDomain в рамках одного рабочего процесса. Рабочий процесс выполняется под специальной учетной записью ASPNET.

Процесс обработки запроса при использовании IIS 5 может быть разбит на следующие шаги:

1. IIS получает запрос, определяет тип ресурса и, если данный тип связан с ASP.NET, передает его на обработку расширению aspnet_isapi.dll. ISAPI расширение передает запрос на дальнейшую обработку рабочему процессу ASP.NET.

2. После получения запроса, рабочий процесс передает сообщение ISAPI расширению, сообщая о том, что запрос будет обработан.

3. Запрос выполняется в контексте рабочего процесса ASP.NET.

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

В случае использования IIS 6 модель обработки запросов несколько меняется, поскольку IIS 6 используем модель пула приложений - отдельного рабочего процесса, который обслуживает одно или несколько веб-приложений. Каждый пул приложений обслуживается отдельным экземпляром рабочего процесса w3wp.exe.

IIS 6 использует для получения и обработки запросов драйвер, работающий на уровне ядра операционной системы http.sys, все запросы проходят через этот драйвер, который отвечает за сопоставление запроса соответствующему пулу приложений. Рабочий процесс, обслуживающий пул приложений, загружает необходимые ISAPI расширения. В случае ASP.NET это расширение aspnet_isapi.dll, которое в свою очередь загружает CLR и начинает обработку HTTP запроса. Рабочие процессы выполняются под учетной записью NetworkService.

2) Структура ASP.NET страницы

Структура страницы ASP.NET 2.0 не отличается от структуры страниц ASP.NET 1.х. Страница по-прежнему разделена на две основные части: директивы и представление. Код программной логики страницы может быть вынесен в отдельный файл (выделенный код, Code Behind), либо включен в представление страницы в качестве блока <script> с установленным атрибутом runat=» server» (встроенный код, inline code)).

Разделение кода программной логики и представления

Рассмотрим оба этих способа размещения кода и различия между подходом к разделению кода в ASP.NET 1.х и 2.0. В ASP.NET 1.x при использовании модели встроенного кода класс страницы ASP.NET наследовал классу System. Web.UI. Page и при выполнении приложения компилировался во временную сборку.

При использовании модели разделения кода и представления в ASP.NET 1.x схема наследования становится более сложной, поскольку классу System. Web.UI. Page наследует класс, определенный в файле программной логики (Code Behind), которому, в свою очередь, наследует класс страницы ASP.NET. При этом класс, определенный в файле программной логики компилируется в единую сборку приложения, находящуюся в директории bin, а класс страницы компилируется во временную сборку.

В ASP.NET 2.0, в связи с появлением возможность разделения классов, общая схема становится несколько иной. Для ASP.NET страницы создается частичный класс страницы (partial class), который объединяется частичным классом, объявленным в файле программной логики, который затем компилируется как единой целое, поэтому в файле с исходным кодом нет декларации элементов управления и создания экземпляров этих элементов. Код, создающий элементы управления, генерируется во время компиляции на основании файла с кодом разметки страницы.

Частичные классы (partial class)

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

Если быть откровенным, то дело обстоит не совсем так, как показано на Рис. 4. Помимо класса, «собранного» из двух частей - частичного класса в файле исходного кода и частичного класса, сгенерированного средой выполнения, существует класс страницы, точно также как и в ASP.NET 1.x наследующий классу, определенному в файле исходного текста.

3) Модель компиляции

В ASP.NET 2.0 по сравнению с ASP.NET 1.x появились новые дополнительные стратегии, связанные с новой моделью компиляции приложений: для каждой ASP.NET страницы создается своя собственная сборка. Эта модель компиляции открывает возможность не перекомпилировать все приложение при изменении одного файла исходного кода, а осуществлять компиляцию только измененных файлов. Поэтому ASP.NET 2.0 предлагает три основных стратегии компиляции приложений:

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

2. Полная прекомпиляция. Абсолютно новая возможность, появившаяся в ASP.NET 2.0 и позволяющая создать одну сборку для всех файлов приложения, включая файлы ASPX, содержащие HTML разметку. Сборка помещается в директорию bin веб-приложения, а содержимое всех ASPX файлов замещается на стоку «This is a marker file generated by the precompilation tool, and should not be deleted!».

3. Динамическая компиляция. Эта стратегия аналогична используемой в ASP.NET стратегии динамической компиляции по запросы, с одним исключением, что страницы компилируются не одновременно, а по мере поступления запросов к каждой конкретной странице.

2.4 ORM-системы. Философия NHibernate

Инкапсуляция. Наследование. Полиморфизм.

Три столпа ООП. И это отнюдь не просто громкие слова. Если что-то пишется объектно-ориентированно, оно должно быть объектно-ориентированно настолько, насколько это возможно.

Однако классическая модель ADO предлагает отнюдь не самый красивый подход. Для получения или изменения данных в базе нам предлагается использовать всё тот же SQL, который можно использовать:

а) в виде встраиваемого кода - худший вариант.

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

Как хорошо заметно, самыми часто выполняемыми запросами к базе являются стандартные, без изысков, запросы на выбор (возможно, с объединением 2-4 таблиц) и запросы на изменение конкретной строки где-то в таблице.

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

Не говоря уже о том, что если в базе, например ~500 таблиц, имеющих сложные связи.

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

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

таблица TEACHER (T-SQL):

CREATE TABLE TEACHER

(

ID int IDENTITY (1,1) NOT NULL,

NAME nvarchar(100) NOT NULL,

IMAGE_ID int NULL,

DESCRIPTION nvarchar(500) NULL,

CONSTRAINT [PK_TEACHER] PRIMARY KEY CLUSTERED

(

[ID] ASC

)

)

ALTER TABLE TEACHER ADD CONSTRAINT FK_TEACHER_IMAGE

FOREIGN KEY (IMAGE_ID) REFERENCES [IMAGE] (ID)

класс-сущность (Entity) Teacher, файл Teacher.cs

using System;

using System. Collections. Generic;

using System. Text;

namespace Core. Model

{

public class Teacher: Entity

{

#region Fields

private string name;

private Image image;

private string description;

#endregion

#region Properties

public virtual string Name

{

get {return name;}

set {name = value;}

}

public virtual Image Image

{

get {return image;}

set {image = value;}

}

public virtual string Description

{

get {return description;}

set {description = value;}

}

#endregion

#region Constants

public const string NamePropertyName = «Name»;

#endregion

}

}

Маппинг класса (Teacher.hbm.xml)

<hibernate-mapping xmlns= «urn:nhibernate-mapping-2.2» assembly= «Core»

namespace= «Core. Model»>

<class name= «Teacher» table=» [TEACHER]» lazy= «true» >

<id name= «Id» column=» [id]">

<generator class= «native» />

</id>

<property name= «Name» type= «string» length= «100» column= «NAME» not-null= «true»/>

<many-to-one name= «Image» class= «Image» column= «IMAGE_ID» not-null= «false» />

<property name= «Description» type= «string» column= «DESCRIPTION» not-null= «false»/>

</class>

</hibernate-mapping>

Как хорошо видно, самой замечательной особенностью NHibernate является то, что ID связанных таблиц не являются просто целочисленными (или GUID) свойствами - они являются ссылками на объект соответствующего класса и чтобы достать фотографию учителя, достаточно в коде просто воспользоваться свойством theTeacher. Image. Всю работу проделает NHibernate и вам не понадобится ни строки кода.

2.5 Паттерны проектирования

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

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

2.5.1 Паттерн MVP

2.5.2 Паттерн «Абстрактная фабрика»

2.5.3 Паттерн Singleton

2.6 Отладка и тестирование

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

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

Уровни тестирования

* Модульное тестирование (юнит-тестирование) - тестируется минимально возможный для тестирования компонент, например, отдельный класс или функция

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

* Системное тестирование - тестируется интегрированная система на её соответствие исходным требованиям

* Альфа-тестирование - имитация реальной работы с системой штатными разработчиками, либо реальная работа с системой потенциальными пользователями / заказчиком на стороне разработчика. Часто альфа-тестирование применяется для законченного продукта в качестве внутреннего приёмочного тестирования. Иногда альфа-тестирование выполняется под отладчиком или с использованием окружения, которое помогает быстро выявлять найденные ошибки. Обнаруженные ошибки могут быть переданы тестировщикам для дополнительного исследования в окружении, подобном тому, в котором будет использоваться ПО.

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

Тестирование «белого ящика» и «чёрного ящика»

В терминологии профессионалов тестирования (программного и некоторого аппаратного обеспечения), фразы «тестирование белого ящика» и «тестирование черного ящика» относятся к тому, имеет ли разработчик тестов доступ к исходному коду тестируемого ПО, или же тестирование выполняется через пользовательский интерфейс либо прикладной программный интерфейс, предоставленный тестируемым модулем.

При тестировании белого ящика (англ. white-box testing, также говорят - прозрачного ящика), разработчик теста имеет доступ к исходному коду и может писать код, который связан с библиотеками тестируемого ПО. Это типично для юнит-тестирования (англ. unit testing), при котором тестируются только отдельные части системы. Оно обеспечивает то, что компоненты конструкции - работоспособны и устойчивы, до определенной степени.

При тестировании чёрного ящика (англ. black-box testing), тестировщик имеет доступ к ПО только через те же интерфейсы, что и заказчик или пользователь, либо через внешние интерфейсы, позволяющие другому компьютеру либо другому процессу подключиться к системе для тестирования. Например, тестирующий модуль может виртуально нажимать клавиши или кнопки мыши в тестируемой программе с помощью механизма взаимодействия процессов, с уверенностью в том, все ли идет правильно, что эти события вызывают тот же отклик, что и реальные нажатия клавиш и кнопок мыши. Как правило, тестирование чёрного ящика ведётся с использованием спецификаций или иных документов, описывающих требования к системе.

Если «альфа-» и «бета-тестирование» относятся к стадиям до выпуска продукта (а также, неявно, к объёму тестирующего сообщества и ограничениям на методы тестирования), тестирование «белого ящика» и «черного ящика» имеет отношение к способам, которыми тестировщик достигает цели.

Бета-тестирование в целом ограничено техникой чёрного ящика (хотя постоянная часть тестировщиков обычно продолжает тестирование белого ящика параллельно бета-тестированию). Таким образом, термин «бета-тестирование» может указывать на состояние программы (ближе к выпуску чем «альфа»), или может указывать на некоторую группу тестировщиков и процесс, выполняемый этой группой. Итак, тестировщик может продолжать работу по тестированию белого ящика, хотя ПО уже «в бете» (стадия), но в этом случае он не является частью «бета-тестирования» (группы / процесса).

Статическое и динамическое тестирование

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

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

Регрессионное тестирование

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

Покрытие кода

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

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

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

При отладке и тестировании веб-представительства и административной подсистемы были использованы методы динамического тестирования: метод «белого ящика», регрессионное тестирование, альфа-тестирование, системное тестирование.

3. Организационный раздел

3.1 Размещение ресурсов сайта

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

Требования к серверу:

• поддержка Windows-хостинга на платформе IIS;

• поддержка ASP.NET 2.0;

• поддержка MS Ajax Extensions;

• поддержка MS SQL Server 2005;

• возможность простого управления сайтом;

• объём жесткого диска под сайт и ресурсы на хосте ~100 мб;

• стоимость услуг, согласованная с заказчиком.

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

Всем этим требованиям удовлетворяет хостинг от русской компании Inform-telecom, на котором в настоящий момент размещён и функционирует сайт.

3.2 Работа с административной подсистемой

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

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

1) Настройка параметров соединения

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

2) Редактирование данных базы.

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

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

Назначения кнопок внизу зависит от того, выделен ли элемент.

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

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

- Изменить (если выбран элемент списка) - вместо сохранения новой записи введённые значения считаются данными для модифицирования старой, выделенной;

- Добавить новое (если выбран элемент списка) - снимет выделение и очищает поля ввода.

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

Заключение

Под руководством моего дипломного руководителя мной была проделана большая подготовительная работа и работа собственно над созданием веб-представительства. Были достигнуты следующие цели:

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

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

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

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

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

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

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

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

Список литературы

1. Э. Гамма, Р. Хелм, Р. Джонсон, Д. Влиссидес. Приёмы объектно-ориентированного проектирования. Паттерны проектирования.

2. Эндрю Троелсен. Язык программирования С# 2005 и платформа.NET 2.0

3. Т. Нортроп, Ш. Уилдермьюс, Б. Райан Основы разработки приложений на платформе Microsoft.NET Framework.

4. Рейли Д. Создание приложений Microsoft ASP.NET