Реферат 1 Введение 3 Аналитическая часть 5
 Скачать 1.24 Mb.
|
Общая архитектура системыАвтоматизируемая система обучения и контроля знаний, в которую интегрируется ролевая система, имеет классическую трехуровневую архитектуру: слой доступа к данным, слой бизнес-логики и слой представления. Приложение построено на платформе ASP.NET MVC. Это означает, что все взаимодействия с пользователем реализованы с помощью HTTP-запросов, обрабатываемых контроллерами. То есть каждой функции модуля соответствует какой-то определённый метод в классе соответствующего контроллера. Слой доступа к данным обеспечивает модели приложения. Реализация пользовательского интерфейса осуществляется с помощью различных элементов HTML страниц (кнопки, формы, ссылки и т.д.). Эти HTML страницы шаблонизированы и выступают в роли представлений. Доступ к слоям бизнес-логики и доступа данных реализован с помощью шаблона «абстрактная фабрика». Абстрактная фабрика – паттерн проектирования, порождающий объекты. Он предоставляет интерфейс для создания семейств взаимосвязанных или взаимозависимых объектов, не указывая их конкретные классы. [27] Эти абстрактные фабрики инкапсулированы в каждом контроллере (фактически, эти фабрики инкапсулируются в родительский класс, от которого наследуются все контроллеры). Таким образом, достигается общая «информационная шина» для всех контроллеров, предоставляющая доступ к слою доступа к данным и слою бизнес-логики. Базовым классом для модулей уровня представления является BaseController, в котором есть поле, содержащее ссылку на класс, реализующий интерфейс IBlFactory. Инициализация этого поля инкапсулирована в этом классе, поэтому в дочернем классе нет необходимости это делать. Так-же, это позволяет упростить тестирование, в случае подстановки тестовой реализации IBlFactory – достаточно изменить его только в базовом классе. Ядром слоя бизнес-логики является класс BlFactory, который реализует 2 интерфейса:
С помощью первого интерфейса с ядром взаимодействует слой представления. Он предоставляет возможность инициализировать ядро (именем пользователя, от которого выполняется запрос – если он есть), а также получать реализации различных интерфейсов модулей бизнес-логики (обобщенный метод GetOf<>). Информация о том, какую реализацию сопоставить интерфейсу, инкапсулирована в классе BlFactory, в поле типа Dictionary Интерфейс IBlManager предназначен для доступа к ядру из самих модулей бизнес-логики. Он позволяет получить имя и идентификатор пользователя, от которого выполняется запрос, а также класс для получения модулей слоя доступа к данным. Установление связи с классом ядра реализовано в базовом классе для модулей бизнес-логики. Ядром слоя доступа к данным является класс DalFactory, который реализует 2 интерфейса:
В самом классе реализован функционал по взаимодействию с БД, с поддержкой транзакций на уровне ORM(Entity Framework), а также, с учетом особенностей этой ORM, оптимизирован процесс установления и разрыва соединения. С помощью интерфейса IDalFactory реализуется взаимодействие модулей слоя бизнес-логики с слоем доступа к данным. С точки зрения слоя бизнес-логики, использовать IDalFactory нужно следующим образом:
Если возникает необходимость, чтобы результат нескольких методов был отправлен в базу данных одним запросом, то перед вызовом этих методов нужно вызвать IDalFactory.BeginTransaction(), а после из вызова – IDalFactory.CommitTransaction(). Также, важен тот факт, что данные транзакции осуществляются на уровне приложения, а не на уровне СУБД, и введены исключительно с целью оптимизации количества запросов к БД. Помимо прочего, соединение с БД не является потокобезопасным, что также необходимо учитывать. В случае, если необходимо многопоточное взаимодействие с БД, нужно для каждого потока создавать свой экземпляр DalFabric(и, соответственно, свое соединение). В качестве базового класса для слоя доступа к данным был создан класс BaseDal, в котором реализованы методы Context для получения экземпляра соединения с БД, метод SaveChanges() для сохранения изменений и метод NoTransaction() для обозначения сложных методов, которые не допускают транзакций на уровне бизнес-логики. С точки зрения слоя доступа к данным процесс работы выглядит следующим образом:
Если на момент вызова SaveChanges ядро находится в состоянии транзакции, то сохранение не будет произведено напрямую в БД, а останется в кеше EntityFramework до её завершения. Передача данных между слоями Разные слои приложения могут использовать разные форматы представления данных(модели). Например, слой доступа к данным для доступа к БД использует классы POCO (Plain old CLR objects), использование которых вне сборки, которая содержит слой доступа к данным может привести к проблемам, связанным с некорректным использованием библиотеки EntityFramework. Если использовать их в другой сборке, то она должна будет также иметь ссылку на библиотеку EntityFramework, что при длительном сопровождении проекта может привести к некорректной работе системы, которая не будет определяться на этапе компиляции, а выявляться только на этапе исполнения. Также, реляционное представление данных не всегда удобно для использования в бизнес-логике приложения, которому требуется более гибкая структура со списками, словарями и ссылками. Для того, чтобы избежать всех этих проблем, вводится такое понятие, как «Основные модели», использование которых возможно во всех модулях проекта. Для избежания циклических ссылок между сборками, все такие модели выносятся в отдельную сборку. Метод работы с ними таков: Методы слоя доступа к данным должен осуществлять «маппинг» (взаимооднозначное преобразование) между «Основными моделями» и POCO. Поэтому, все его методы должны принимать на вход только классы из категории основых моделей. Методы слоя бизнес-логики должны работать в рамках основных моделей. Методы слоя представления могут передавать на клиент как основные модели, так и специализированные «модели представления», которые составляются на основе основных моделей. К сожалению, в случае простых модулей, такой подход может привести к повторному написанию кода – когда основная модель абсолютно не отличается от POCO. Но, в рамках сложного и расширяемого проекта, плюсы такого подхода перевешивают минусы. |