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

Начнём рассмотрение с самого верхнего уровня и будем спускаться ниже, изучая структуру сайта.

На самом верхнем уровне лежит классическая модель клиент-сервер-БД, к которой добавлено несколько промежуточных уровней.

Как видно из схемы, клиент взаимодействует с сервером 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.

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