Проектирование иерархии моделей данных в многослойном приложении

При проектировании многослойной архитектуры приложения одной из главных задач является формирование набора моделей данных каждого слоя и определение порядка взаимодействия моделей данных между собой. Под взаимодействием понимаются потоки данных, передаваемые из одной модели данных в другую. В общем случае взаимодействие между моделями данных двунаправленное.

Рассмотрим модель данных application model, которая потребуется в дальнейшем изложении и которая используется в паттерне CQRS.

Реализация архитектурного паттерна CQRS, используемого приложением в функционале application logic, представляет собой набор классов наследников базовых классов QueryHandler / CommandHandler и набор классов данных, которые являются наследниками базовых классов Query / Command. Классы наследники Query / Command представляют собой модель данных application logic. Такую модель данных логично назвать application model.

Используя application model и другие известные модели данных слоёв приложения можно построить полную схему взаимодействия моделей данных многослойного приложения.

Модели данных слоя приложения можно разбить на два типа – модели данных фасада слоя и модели данных логики слоя. Как будет показано далее, модель данных логики слоя изолирована внутри слоя и к ней нет доступа из других слоёв приложения.

В дальнейшем изложении используется структура слоёв приложения, которая приведена на рисунке 1 в статье «Разработка архитектуры приложения с использованием слоёв, подслоёв и архитектурных блоков».

В каждом из слоёв приложения facade layer, logic layer и persistence layer используется две разные модели данных – одна для фасада слоя, а вторая для логики слоя.

Для приложения с визуальным интерфейсом моделью данных фасада слоя facade layer является контейнер данных, который представляет собой набор элементов управления на визуальной форме, в которых можно ввести, вывести или выбрать данные из уже готового списка данных. Для веб-сервиса моделью данных фасада слоя facade layer представляет собой контейнер данных в виде data stream, при помощи которого приложение получает данные запроса от внешнего консюмера и отправляет внешнему консюмеру данные ответа на запрос.

Моделью данных логики слоя facade layer является view model для приложений с визуальным интерфейсом и data transfer model для веб-сервисов.

Application logic представляет собой фасад слоя logic layer и application model является моделью данных фасада слоя logic layer. Application model является посредником при обмене данными между facade layer и моделями данных нижележащих слоёв приложения. Application model скрывает от слоя facade layer другие модели данных нижележащих слоёв приложения.

Моделью данных логики слоя logic layer является domain model.

Моделью данных фасада слоя persistence layer является модель данных persistence model.

Если в приложении для работы с данными используется технология ADO.NET, то в качестве модели данных логики слоя persistence layer используются объекты типа DataTable и DataReader, которые являются контейнерами данных, которые приложение получает из баз данных. Если используются другие технологии для работы с внешними данными, то будут использованы другие типы объектов-контейнеров для внешних данных в соответствии с выбранной технологией.

В таблице представлен набор моделей данных с привязкой к слоям приложения.

На рисунке 1 представлена структурная схема взаимодействия моделей данных слоёв в многослойном приложении.

Используя приведенную выше схему взаимодействия моделей данных можно детально описать структуру паттерна Model-View-ViewModel. В приложениях с визуальным интерфейсом слой facade layer обычно называют presentation layer. Далее будет использован термин presentation layer.

Паттерн Model-View-ViewModel решает две основные задачи.

1. Описывает порядок взаимодействия между собой элементов View и ViewModel слоя presentation layer.

2. Описывает взаимодействие между presentation layer и функционалом application logic нижележащего слоя logic layer.

Элемент паттерна View используется двояко – как функциональный элемент и как контейнер данных. View как функциональный элемент представляет собой набор обработчиков событий элементов управления на визуальной форме. View как контейнер данных представляет собой набор элементов управления на визуальной форме, в которых можно ввести, вывести или выбрать данные из уже готового списка данных (combobox, listbox).

На рисунке 2 представлена структурная схема паттерна MVVM с разбиением на потоки вызовов и потоки данных.