惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

J
Java Code Geeks
量子位
MongoDB | Blog
MongoDB | Blog
N
Netflix TechBlog - Medium
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
B
Blog
A
About on SuperTechFans
腾讯CDC
The GitHub Blog
The GitHub Blog
云风的 BLOG
云风的 BLOG
雷峰网
雷峰网
Last Week in AI
Last Week in AI
H
Help Net Security
WordPress大学
WordPress大学
博客园 - 司徒正美
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
H
Hackread – Cybersecurity News, Data Breaches, AI and More
T
Tailwind CSS Blog
博客园 - 【当耐特】
S
SegmentFault 最新的问题
美团技术团队
M
MIT News - Artificial intelligence
L
LangChain Blog
博客园 - 聂微东

Все публикации подряд на Хабре

Ловим музу за клавиатуру: как айтишнику стать автором Что умеет Midjourney в 2026? Мой немного грустный разбор этого шикарного инструмента Никто не любит писать тесты, но ИИ может исправить это IPv8 выглядит как мечта. Поэтому почти наверняка не взлетит Производители вернули в продажу материнки с DDR3. Что происходит? Управление агентом с телефона через Telegram теперь в KodaCode От координации к лидерству: как меняется роль руководителя разработки Я сделала родителям бизнес вместо пенсии: зарабатываем 70 тысяч, мама не даёт продать В три раза быстрее приемка товара и оптимизация трудозатрат на 73%: как «РСТ-Инвент» помог Gulliver Group ИИ-шечный мир победил? О влиянии искусственного интеллекта на игропром Кремль снижает давление на Телеграмм пока Европа строит интернет по паспорту Как CEO, CTO и CIO за 8 часов собрали ИИ-директора, который умеет держать позицию под давлением Как (не) потерять домен за выходные Вместо 8 разных VPS: как я организовал практику студентам на одном сервере Почему твой Open Source проект не замечают? R&D: искусство управления неопределенностью в разработке AI-дефляция: вакансий для разработчиков больше, а рост зарплат — худший за 15 лет Мы отдали управление роботами OpenClaw. Что из этого вышло Галактический ID: система идентификации для всех форм разумной жизни Шесть основ бизнес-анализа: начинаем с вопроса «Кто в игре?» Код-ревью, в котором дело не в коде Данные переехали. Команда — нет Системной подход к сдаче OSWE в 2025 Почему комната управления реактором покрашена в цвет морской пены 4 YAML-файла вместо PySpark: как аналитикам строить пайплайны без разработчиков LLM-агент для поиска свободных доменов: автоматизируем подбор Когда, зачем и как правильно начинать новую сессию в Claude Code? Как я заставил нейросеть писать макросы для FreeCAD Анатомия ИИ‑агента для подбора персонала. От тысячи резюме к топ‑10 за минуты Опыт разработчика как экономика внимания
Проектирование иерархии моделей данных в многослойном при...
AlexViolin · 2026-04-23 · via Все публикации подряд на Хабре

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

Уровень сложностиСредний

Время на прочтение4 мин

Охват и читатели1.1K

Обзор

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

Рассмотрим модель данных 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, которые являются контейнерами данных, которые приложение получает из баз данных. Если используются другие технологии для работы с внешними данными, то будут использованы другие типы объектов-контейнеров для внешних данных в соответствии с выбранной технологией.

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

Facade layer (для приложений с визуальным интерфейсом)

Модель данных фасада слоя

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

Модель данных логики слоя

View model

Facade layer (для веб-сервисов)

Модель данных фасада слоя

Контейнер данных в виде data stream, при помощи которого приложение получает данные запроса от внешнего консюмера и отправляет внешнему консюмеру данные ответа на запрос

Модель данных логики слоя

Data transfer model

Logic layer

Модель данных фасада слоя

Application model

Модель данных логики слоя

Domain model

Persistence layer

Модель данных фасада слоя

Persistence model

Модель данных логики слоя

DataTable, DataReader при использовании технологии ADO.NET

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

Рисунок 1

Рисунок 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 с разбиением на потоки вызовов и потоки данных.

Рисунок 2

Рисунок 2