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

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

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

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

- самоописывающиеся объекты, которые делают ненужным использование 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 Паттерны проектирования

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

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

Страницы: 1, 2, 3, 4, 5, 6