Связанные данные в трехуровневой архитектуре

@Cherry_Pie · Регистрация: 16.12.2017

Студворк — интернет-сервис помощи студентам

Как подтягивать связанные данные в трехуровневой архитектуре?
У меня есть три уровня данных.
На уровне DAL там понятно как обращаться к связанные данным, там есть связи.
Вот на пример в DAL заказ у меня выглядит так

C#
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
  
public class Order
    {
        public Order()
        {
            this.OrderItems = new HashSet<OrderItem>();
        }
        public Guid OrderId { get; set; }
        public Guid CustomerId { get; set; }
        public DateTime OrderDate { get; set; }
        public DateTime? ShipmentDate { get; set; }
        public int? OrderNumber { get; set; }
        public Guid? StatusId { get; set; }
 
 
        public virtual Customer Customer { get; set; }
        public virtual ICollection<OrderItem> OrderItems { get; set; }
        public virtual Status Status { get; set; }
    }

Уровень BLL DTO

C#
1
2
3
4
5
6
7
8
9
 public class OrderDTO
    {
        public Guid OrderId { get; set; }
        public Guid CustomerId { get; set; }
        public DateTime OrderDate { get; set; }
        public DateTime? ShipmentDate { get; set; }
        public int? OrderNumber { get; set; }
        public Guid? StatusId { get; set; }
    }

Уровень представления у меня 2 модели

C#
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
//Просто вывод списка заказов
    public class OrderListModel
    {
        public Guid OrderId { get; set; }
        public Guid CustomerId { get; set; }
        public int? OrderNumber { get; set; }
        public Guid? StatusId { get; set; }
    }
 
//Вывод более подробной информации 
 public class OrderViewModel
    {
        public Guid OrderId { get; set; }
        public Guid CustomerId { get; set; }
        public DateTime OrderDate { get; set; }
        public DateTime? ShipmentDate { get; set; }
        public int? OrderNumber { get; set; }
        public Guid? StatusId { get; set; }
        
    
        public IEnumerable<OrderItemListModel> ItemsList { get; set; }
    }

Из этого следует вопрос как получить связанные данные. Что бы на пример вместо ID статуса вылезала надпись (в таблице статус 2 поля (ID,Name)) мне нужно чтобы он подставлял Name. И что бы в подробностях заказа был список товаров.

Как вариант переносить связи на каждый уровень.
Какие еще варианты?

@sau · 26.09.2019, 00:48

Сообщение от Cherry_Pie

сделать код товаров, заказчиков быть именно в «выдуманны форматах».

я вот эту фразу не понял , мы говорим про код товара или же про код заказа ?

если про номер заказа , то можно Item.Code => Шифровать(ид.клиента+время.заказа) - это почти уникально , шансов на то , что один и тот же клиент сможет сделать более одного заказа за долю секунды почти нет (если только не программой , но тогда просто уведомить , что заказ уже есть)
если про номер товара - то обычно у реального товара он уже есть по накладной , если представить что нет - у нас же сказочный проект ) ? - тогда можно генерировать номер по параметрам товара Item.Code => Шифровать(код страны , номер бренда , категория , номер цвета). В общем пофантазируйте , поскольку требования надуманные то и реализация может быть какой угодно.

@Cherry_Pie · 26.09.2019, 13:36 **[ТС]**

sau, спасибо, понял. Ну а то, что я это делаю прям в сервисе, где по задумке должна быть "перегонка" данных из модели в модель, это нормально? или это нужно выносить куда-то бизнес объекты?

@sau · 26.09.2019, 13:44

Сообщение от Cherry_Pie

или это нужно выносить куда-то бизнес объекты?

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

@Cherry_Pie · 26.09.2019, 17:22 **[ТС]**

sau, как правильно выводить заказ и связанные с ним элементы, через include? Я тупа в таблице OrderItem по orderID вывел. Это рабочий вариант?

@sau · 26.09.2019, 17:41

А кто с этой карточкой будет работать ? - если оператор , то для него идентификаторы записей из БД тут будут лишние , должны быть информативные сведения - наименование товара (код) , имя заказчика , читаемый статус заказа. , оператор по этим данным общается с клиентом , и ему , например , нужно быстро поменять состав заказа если клиент передумал.
По этому , как правильно и в каком виде - зависит от потребностей.
Какая цель у редактирования ?

@Cherry_Pie · 26.09.2019, 18:26 **[ТС]**

sau, Да, будет работать оператор. это понятно, что вместо iD должны быть нормальные данные. И в статусе заказа должен быть dropdown с выбором статуса, я просто до этого ещё не дошёл, но вообще эта тема и создавалась по этому вопросу)

Добавлено через 5 минут

Сообщение от sau

Какая цель у редактирования ?

Смена статуса заказа

Добавлено через 7 минут
sau,

Сообщение от sau

то для него идентификаторы записей из БД тут будут лишние , должны быть информативные сведения - наименование товара (код) , имя заказчика , читаемый статус заказа. ,

Я просто не знаю как это реализовать, в DTO у меня хранится только ID и во View следовательно я могу передать ID. Ну либо делать выборку по ID и тогда уже подтягивать данные.

@sau · 26.09.2019, 20:14

Cherry_Pie, ну так а что вам мешает сделать доменную модель ?
- ее и маппируйте на модель представления.

@Cherry_Pie · 26.09.2019, 20:19 **[ТС]**

sau, Так а как ее делать? С этого я начал эту тему)
вот есть в DAL модель БД

C#
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
public class Order
    {
        public Order()
        {
            this.OrderItems = new HashSet<OrderItem>();
        }
 
        public Guid OrderId { get; set; }
        public Guid CustomerId { get; set; }
        public DateTime OrderDate { get; set; }
        public DateTime? ShipmentDate { get; set; }
        public int? OrderNumber { get; set; }
        public Guid? StatusId { get; set; }
 
 
        public virtual Customer Customer { get; set; }
        public virtual ICollection<OrderItem> OrderItems { get; set; }
        public virtual Status Status { get; set; }
    }

Вот в BL DTO модель

C#
1
2
3
4
5
6
7
8
9
    public class OrderDTO
    {
        public Guid OrderId { get; set; }
        public Guid CustomerId { get; set; }
        public DateTime OrderDate { get; set; }
        public DateTime? ShipmentDate { get; set; }
        public int? OrderNumber { get; set; }
        public Guid? StatusId { get; set; }
    }

Нужно в BL добавить Domain модель со всеми связями? или как?

Добавлено через 1 минуту
sau, В интернете везде Domain = моей DTO, просто кто-то ее называет DTO, а кто-то Domain.
А смысл один и тот же

@sau · 26.09.2019, 20:39

Сообщение от Cherry_Pie

В интернете везде Domain = моей DTO, просто кто-то ее называет DTO, а кто-то Domain.
А смысл один и тот же

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

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

@Cupko · 26.09.2019, 20:48

sau, я, на самом деле, не совсем понимаю почему вы топите за отсутствие суррогатных айдишников в доменной модели. Вы реально практикуете это?

@Cherry_Pie · 26.09.2019, 20:50 **[ТС]**

sau, Так, получается так.
Я из DAL с помощью сервисов передаю в данные в DTO где храняття такие же поля с IDшниками?
Потом из DAL передаю в Domain. из domain передаю во View?
Можете на примере одной(например товара) сущности расписать цепочку от модели БД до модели представления?

@sau · 26.09.2019, 21:03

Что бы было понятнее , бизнес логика так или иначе оперирует какими то сущностями , т.к логика не может оперировать воздухом. , в результате описывается какой то процесс , поведение , результат действия.
оформление заказа или изменение номера заказа - это не просто редактирование поля , это процесс, которая может быть простым а может быть и сложным - согласования , проверки , уведомления , растянутость во времени = бизнес логика.
для воплощения процесса зачастую нужно гонять данные между подсистемами в инфраструктурном слое , обмениваться данными между внешними службами - тут делаем dto , они будут разные для тех или иных случаев , и сохранение в бд лишь один из частных сценариев, в то время как построение концептуальной модели предметной области никак не зависит от инфраструктуры и сервисных служб с их требованиями к транспортировке данных.

У Вас речь идет о простом приложении , с архитектурой по типу view-data , когда данные из БД напрямую транслируются интерфейсу и обратно. , тут собственно для реализации целей редактирования ничего не нужно , берете репозиторий , получаете от него данные , маппируете их на то или иной представление = готово , тоже самое обратно.

Cupko, смотря что под id понимать , если это как у Эрик Эванса идентификатор сущности - т.е атрибут идентификации обьекта в реальном мире , такой как фио например - то разумеется это атрибут доменной модели.
если мы говорим об идентификаторе хранилища , или идентификаторе сессии , или любых других идентификаторах которые могут быть в транспортных обьектах - то Вы не сможете их все уместить в доменной модели да и нелепо они будут там смотреться , эти идентификаторы не имеют никакого отношения к бизнесу и никак не юзаются в бизнес процессах , это чисто технические поля , которые могут меняться в зависимости от системы транспорта или технических условий для хранения данных.

@Cupko · 26.09.2019, 21:07

sau, я понимаю о чем вы. Я конкретно о практике.
Это всё хорошо, конечно. Чистая доменная модель - это поддерживаемость, ясность кода и красота.
Тут вопрос в другом: насколько накладные расходы на отсутствие суррогатных ключей будут эту всю поддерживаемость улучшать.
С учетом того, что какой-нибудь EF (в проекте с EF) требует наличие этого суррогатного ключа.
Не считая моментов с производительностью баз. В целом, для приложения.

@IamRain · 26.09.2019, 21:08

Cherry_Pie, да не заморачивайтесь вы с терминологией так, со временем все разложится по полкам.
А то читаешь это все - "DAL туда, Domain обратно, c помощью сервисов" Голова закружится

Вот берете любую статейку по DDD
и смотрите:

Mainly, domain driven design focuses on:

The core domain and domain logic

Complex designs on models of the domain

Improving the application model and resolving emerging domain-related issues by collaborating with domain experts

Дальше смотрим, Core Domain - что это? - Это наверно наши модельки.
Ага, точно:

Model
The model is a system that describes the selected aspects of a domain and that is often used to solve problems that are related to that particular domain.

Читаем дальше:

What are the characteristics of a strong domain model?
Being isolated
Being reusable

Получается и ваши Dto и ваши объекты из DbContext-а - это все Domain-модели, доменные модели, черт побери. Просто описывающие различные аспекты работы. Вот и все.

Ах да, ведь у нас еще есть и Domain Logic. А это все реализуется в виде сервисов в отдельной сборке.
Итого физически весь домен валяется в двух сборках:
1. CompanyName.ApplicationName.Domain - сюда пихаем все доменные модели (сущности из БД, вьюмодели, Dto-хи различного типа/назначение)
2. CompanyName.ApplicationName.Core - сюда вся бизнес-логика - основная и вспомогательная (даже маппинг). Хорошая архитектура, между прочим, получается.

@Cherry_Pie · 26.09.2019, 21:10 **[ТС]**

Cupko, sau, Может зайдем в скайп на совещания?))

@IamRain · 26.09.2019, 21:11

Сообщение от Cupko

не совсем понимаю почему вы топите за отсутствие суррогатных айдишников в доменной модели.

Согласен с вами, Ну есть ключи, и да ладно. Связи ведь надо сохранять, но это не значит что надо сразу говорить что это не доменная модель. Так или иначе вся доменная модель построена на основе данных - а данные - лежат (чаще всего) в базе.

@sau · 26.09.2019, 21:14

IamRain, а это смотря у кого читать определения )
все таки есть эталоны , а есть статейки непойми от кого со своей собственной интепретацией и видинием.

Проектирование на основе предметной области (DDD, Domain-driven design) — это подход к разработке программного обеспечения для комплексного удовлетворения потребностей, путем сильной связи реализации с основными бизнес-моделями, находящимися в процессе постоянного развития.

@sau · 26.09.2019, 21:16

но мы не будем сейчас тут усложнять конечно , все таки не энтерпрайз пишем.

@sau · 26.09.2019, 21:19

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

@Cherry_Pie · 26.09.2019, 21:21 **[ТС]**

Ну на теории все понятно, есть БД, есть слой который гоняет данные из неё/в неё.
Есть бизнес логика которая работает с ними. Все понятно, а как реализовать то? Просто на словах все понятно.
Что конкретно добавить/ изменить нужно у меня?
Может посмотрите что у меня имеется?
Только сильно не смейтесь
https://drive.google.com/file/... sp=sharing

Добавлено через 21 секунду

Сообщение от sau

но мы не будем сейчас тут усложнять конечно , все таки не энтерпрайз пишем.

хахахахахахахаха

Новые блоги и статьи Все статьи Все блоги /
Был там один разговор по поводу свободы в материальном мире. kumehtar 19.08.2026 Суть: рассматривается живое существо, оказавшееся внутри довольно странной системы (этого мира) и пытающееся обустроить в ней свой кусок пространства. Жизнь действительно предъявляет каждому. . .	Когда логика программы не спасает от человеческих ошибок Maks 18.08.2026 В последнее время всё чаще и чаще сталкиваюсь с таким явлением, как абсолютная невнимательность (или глупость) пользователей. Проявляется это чаще всего на работе в коллективе. Допустим, человек с. . .	Лето уходит kumehtar 17.08.2026	Мысли в слух kumehtar 17.08.2026 Забавно, насколько сейчас стала доступна информация. Например о магии, духовном развитии, медитациях, и других подобных направлениях, ранее зачастую тайных, передаваемых от учителя к ученику. Хотя. . .
Перемещение строк из ТЧ в другой документ с учетом текущего пробега Maks 17.08.2026 Реализация из решения ниже выполнена на примере нетипового документа "Автозапчасти", с ТЧ "Шины". За основу взят алгоритм отсюда: https:/ / www. cyberforum. ru/ blogs/ 359708/ 10838. html Задача: . . .	Саморегулирующийся социальный контракт для сервера cross-section. Hrethgir 14.08.2026 С кодом конечно таких глубоких размышлений пока не было, впрочем я уже привык к алгоритмизации. Суть предмета записи: снова в диалоге с нейросетью (я взял пока себе ник для учётки админа - Rector). . . .	Часы электронные Uhbif79 12.08.2026 Выкладываю программу часов. Программа позволяет: 1. Использовать системное время и дату, 2. Есть возможность вводить время и дату вручную. 3. Реализованы 2 будильника: начало и конец рабочего дня. . . .	Часы с будильником на основе класса QLCDNumber Uhbif79 12.08.2026 Всем добрый день, выкладываю программу часов с будильником на основе класса QLCDNumber. Здесь я пробовал самостоятельно создавал классы, впервые столкнулся с видимостью переменной одного класса из. . .

@Cherry_Pie 16 / 10 / 4 Регистрация: 16.12.2017 Сообщений: 281
	26.09.2019, 13:36 [ТС]
	sau, спасибо, понял. Ну а то, что я это делаю прям в сервисе, где по задумке должна быть "перегонка" данных из модели в модель, это нормально? или это нужно выносить куда-то бизнес объекты? 0

@Cherry_Pie 16 / 10 / 4 Регистрация: 16.12.2017 Сообщений: 281
	26.09.2019, 17:22 [ТС]
	sau, как правильно выводить заказ и связанные с ним элементы, через include? Я тупа в таблице OrderItem по orderID вывел. Это рабочий вариант? Миниатюры 0

@sau 2875 / 2080 / 386 Регистрация: 22.07.2011 Сообщений: 7,837
	26.09.2019, 17:41
	А кто с этой карточкой будет работать ? - если оператор , то для него идентификаторы записей из БД тут будут лишние , должны быть информативные сведения - наименование товара (код) , имя заказчика , читаемый статус заказа. , оператор по этим данным общается с клиентом , и ему , например , нужно быстро поменять состав заказа если клиент передумал. По этому , как правильно и в каком виде - зависит от потребностей. Какая цель у редактирования ? 0

@sau 2875 / 2080 / 386 Регистрация: 22.07.2011 Сообщений: 7,837
	26.09.2019, 20:14
	Cherry_Pie, ну так а что вам мешает сделать доменную модель ? - ее и маппируйте на модель представления. 0

@Cupko 658 / 595 / 171 Регистрация: 17.07.2012 Сообщений: 1,682 Записей в блоге: 1
	26.09.2019, 20:48
	sau, я, на самом деле, не совсем понимаю почему вы топите за отсутствие суррогатных айдишников в доменной модели. Вы реально практикуете это? 0

@Cherry_Pie 16 / 10 / 4 Регистрация: 16.12.2017 Сообщений: 281
	26.09.2019, 20:50 [ТС]
	sau, Так, получается так. Я из DAL с помощью сервисов передаю в данные в DTO где храняття такие же поля с IDшниками? Потом из DAL передаю в Domain. из domain передаю во View? Можете на примере одной(например товара) сущности расписать цепочку от модели БД до модели представления? 0

@sau 2875 / 2080 / 386 Регистрация: 22.07.2011 Сообщений: 7,837
	26.09.2019, 21:03
	Что бы было понятнее , бизнес логика так или иначе оперирует какими то сущностями , т.к логика не может оперировать воздухом. , в результате описывается какой то процесс , поведение , результат действия. оформление заказа или изменение номера заказа - это не просто редактирование поля , это процесс, которая может быть простым а может быть и сложным - согласования , проверки , уведомления , растянутость во времени = бизнес логика. для воплощения процесса зачастую нужно гонять данные между подсистемами в инфраструктурном слое , обмениваться данными между внешними службами - тут делаем dto , они будут разные для тех или иных случаев , и сохранение в бд лишь один из частных сценариев, в то время как построение концептуальной модели предметной области никак не зависит от инфраструктуры и сервисных служб с их требованиями к транспортировке данных. У Вас речь идет о простом приложении , с архитектурой по типу view-data , когда данные из БД напрямую транслируются интерфейсу и обратно. , тут собственно для реализации целей редактирования ничего не нужно , берете репозиторий , получаете от него данные , маппируете их на то или иной представление = готово , тоже самое обратно. Cupko, смотря что под id понимать , если это как у Эрик Эванса идентификатор сущности - т.е атрибут идентификации обьекта в реальном мире , такой как фио например - то разумеется это атрибут доменной модели. если мы говорим об идентификаторе хранилища , или идентификаторе сессии , или любых других идентификаторах которые могут быть в транспортных обьектах - то Вы не сможете их все уместить в доменной модели да и нелепо они будут там смотреться , эти идентификаторы не имеют никакого отношения к бизнесу и никак не юзаются в бизнес процессах , это чисто технические поля , которые могут меняться в зависимости от системы транспорта или технических условий для хранения данных. 0

@Cupko 658 / 595 / 171 Регистрация: 17.07.2012 Сообщений: 1,682 Записей в блоге: 1
	26.09.2019, 21:07
	sau, я понимаю о чем вы. Я конкретно о практике. Это всё хорошо, конечно. Чистая доменная модель - это поддерживаемость, ясность кода и красота. Тут вопрос в другом: насколько накладные расходы на отсутствие суррогатных ключей будут эту всю поддерживаемость улучшать. С учетом того, что какой-нибудь EF (в проекте с EF) требует наличие этого суррогатного ключа. Не считая моментов с производительностью баз. В целом, для приложения. 0

@Cherry_Pie 16 / 10 / 4 Регистрация: 16.12.2017 Сообщений: 281
	26.09.2019, 21:10 [ТС]
	Cupko, sau, Может зайдем в скайп на совещания?)) 0

@sau 2875 / 2080 / 386 Регистрация: 22.07.2011 Сообщений: 7,837
	26.09.2019, 21:16
	но мы не будем сейчас тут усложнять конечно , все таки не энтерпрайз пишем. Миниатюры 0

@sau 2875 / 2080 / 386 Регистрация: 22.07.2011 Сообщений: 7,837
	26.09.2019, 21:19
	Если Вы действительно пишете многослойное и многозвенное приложение , то это куча микросервисов со своим прицелом, распределенные по разным машинам , с разными структурами передачи и хранения данных , все в совокупности юзается бизнес логикой через инфраструктурные службы , и по этому dto-шки которые гоняются между сервисами по сети , и между базами - это не доменная модель. , от слова совсем. И если мы уж делаем некое ее подобие (или не делаем ?) , хотя бы на уровне монолита , то сразу говорим о том , что транспортным айдишникам в ней не место. 0