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

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

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

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

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

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

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

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

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

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

Рассмотрим оба этих способа размещения кода и различия между подходом к разделению кода в 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