Блин, господа, вы серьёзно обсуждаете стоит ли возвращать сущность БД

из контроллера?

Ты начал это 😁

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

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

нет, блин, он возвращает не зная что он возвращает, в этом проблема

Хорошо, представь, что тебе нужно вернуть объекты Подразделения Внутри есть ссылка на родительское подразделение Также навигационное свойство с коллекцией дочерних подразделений и навигационное свойство на подразделение человека, который сосудам текущее подразделение Id, ParentId, CreateDivisionId, Children Попробуй просто взять и смапить это в дто в древовидном и вернуть результат через апи И поймешь что дело не в дто

На этапе создания ДТО я пойму что делаю херню

Ну задача стоит вывести древовидный список)

выводите. Никаких циклических связей это не требует

вроде бы ребята предлагают брать сущность из EFCore"ки с инклюдами и прочим, размапливать в детерминированную DTOшку и возвращать её

Стикер

при чём тут ef вообще?

Кстати, еще в копилку, если тебе потом в контроллере все равно надо будет мапить это дело, чтобы возвращать, то почему бы и сразу не делать это?

у нас просто сложилась практика возвращать те же модели, что лежат в БД, наружу. Мы толком не размапливаем, если это не какая-то необходимость

Ничего не предлагали такого. За инклюды надо бить по пальцам обычно. Или по голове.

почему за инклюды надо бить по голове? Если мы говорим про работу с EFCore и заполнение ICollection в модели по заполненным ключам в модель билдере?

Потому что использующий код не знает что было заинклужено. Еще хуже когда это возвращается из апихи и не покрыто тестами и вы узнаете о проблеме только когда клиент отвалится (а отвалится только когда захочет получить имено это поле)

И какая альтернатива? При работе с EFCore я использую инклюды, когда мне нужно заполнить, например, модель Menu данными из связанных один-ко-многим ICollection<MenuItem> MenuItems. Используя LINQ я задаю SQL через LINQ-to-Entities в процессе формирования IQueryable запроса в БД. Указанные мной в модель билдере ключи и отношения позволяют ORM сделать за меня оптимальную работу по поиску связанных объектов и вернуть мне коллекцию. Я понимаю, что можно пойти альтернативным путём, и сходу приходит вариант с отдельной выборкой MenuItems.Where(x => x.IdMenu == idMenu), и затем вкладывать в DTO эти MenuItems в отдельную менюшку. Но когда речь заходит о формировании контракта с отношениями многие-ко-многим, этот вариант не сработает. Как тут поступить? Если ManyToMany, которое обеспечивает нам EFCore, ты считаешь плохим?

dbContext.Where(condition).Select(selector).ToArrayAsync() Все оптимально, база сделала все самым лучшим способом :)

Я не очень понимаю почему это проблема метода. Если тебе нужен метод GetMenu, но без ICollection внутри, то можно * сделать две версии метода - с коллекциями и без * билдить инклюды по необязательному входному параметру, всё же инклюд это IQueryable, который можно обернуть в if и не будет проблем. "не знает" это ерунда, если у тебя метод задокументировал. Для чего нам XML-комментарии, как не для того, чтобы навести на название метода курсор и быстро узнать о возможностях метода?

Я ничего плохим не считаю, я даже согласен, что иногда инклуд нужен. Как и навигационные свойства. Но лучший ли это путь надо подумать трижды

это для многие-ко-многим? Как с этим работать? Пример: Systems и Users. В каждой системе много пользователей, у каждого пользователя много систем.

Пока не поинмаю, какая разница, у тебя в EFе уже есть вложенные свойства, разве нет? В чем проблема с их маппингом?