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

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

Не говоря уже о том, что если в базе, например ~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

 Скачать реферат