Пацаны, столкнулся с концептуальной проблемой! Подскажите, по чистой архитектуре: Делаю проект

Question

Пацаны, столкнулся с концептуальной проблемой! Подскажите, по чистой архитектуре: Делаю проект

по типу как у Ардалиса организован eShopOnWeb
Решил вынести DTO в отдельный проект как class library, чтобы юзал и клиент и сервак.
Мой слой Бизнес логики знает про DTO, так как мои сервисы сразу отдают ДТО в слой представления. То есть Application.Core референсит Application.DTO
Но, мои ДТОшки должны знать об общих типах и енамах, которые у меня соответственно лежат в Application.Core. Получается циклическая зависимость, надо что то делать) Пока додумался только Common вытащить еще в один отдельный проект, но не криво ли?)

#oop #programming #russian #software #web-design

0

14.09.2022

2 ответов

13 просмотров

Prokhor Vernikovskiy Автор вопроса

Evgenii Morozov
Я в какой-то момент вместо енумов в ДТО стал испол...

Привет! Спасибо за идеи! 1) Я тоже думал разобраться с енамом через строки, а с ValueObjectами, просто размапив их на атрибуты с примитивными типами. Но у меня еще есть классы вроде Vector3, MyRange и полюбому наберется еще по ходу проекта. Сейчас они тихонько лежат в Application,Core. 2) Изменение ДТО влекущее изменение Кора - думаю, это не проблема, так как ДТО и КОР - это по сути одно и то же, и если тебе нужно реализовать или расширить контракт, то где-то ты должен написать и логику. (!) 3) Разные представления моих ентити - это вполне могут быть разные ДТО - так обычно и делают в проектах и никого не смущает, что на одну сущность есть куча дто - CityInputDTO, CityPatchDTO, CityDTO и так далее

0

14.09.2022

Evgenii Morozov · Accepted Answer

Я в какой-то момент вместо енумов в ДТО стал использовать строки. Строки в енумы и енумы в строки преобразуются всё-равно автоматически, но при этом строка даёт возможность избежать этой связи. Если коммон и кор будут зависеть от одного набора енумов, то изменяя ДТО, автоматически изменится кор. Т.е. или иметь два набора енумов или один для кора, а в ДТО их чем-то заменить. Основная идея же в том, чтобы ДТО и кор были бы независимы. Если общие типы - это как примитивы языка, какое-то как будто бы его расширение, то я бы вынес в отдельную библиотеку. На мой взгляд, основная задача в этих зависимостях сохранить независимость именно кора. Чем-то скорее всего придётся пожертвовать. Кстати, для размышления над этим вопросом может быть полезно представить ещё какой-нибудь интерфейс, например, messaging. Т.е. получается как бы второй АПИ, в который объекты кора должна уметь как-то преобразовываться.

212 похожих чатов

Пацаны, столкнулся с концептуальной проблемой! Подскажите, по чистой архитектуре: Делаю проект

2 ответов

Похожие вопросы