Gluck_13Хуже, когда нужно достать из БД N карточек, подпадающих под определенное условие, с включением M навигационных свойств.

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

Этот бред уже переваливает за край. Накуй пользователю эти ваши M навигационных свойств? И зачем дрочить базу данных, канал связи, оперативу и мозг по этому поводу? Бери только то, что нужно, именно так работают с базой данных.

skyANAhVostt, это хорошо, когда одно View, где нужен один набор проекций.

А когда у тебя K представлений, то начинаются вопросы.
А если данные нужны не для отображения а для массовой обработки?

Вообщем проекции постепенно перестают быть DTO и начинают пролазить в бизнес-логику :)

Если речь идёт о попытке сэкономить на кодировании, городя К представлений, то это весьма наивно.

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

skyANAНе понял мысль.

Ок

skyANAА когда у тебя K представлений, то начинаются вопросы.

Надо понимать, что представлений обычно больше, чем 1.
У меня вопросов по этому поводу не возникает. Ну К, так К. Или М. Чем больше требуется представлений, тем сложнее приложение, это нормально.

skyANAА если данные нужны не для отображения а для массовой обработки?

Какой, вычисления? Ну тем более, через отражения легко аккумулировать данные. Если требуются сложные вычисления, которые невозможно (или нерационально) выполнять на уровне запросов, то какая разница, как брать данные? Требуется трансфер и преобразование данных? Тоже самое, с проекциями можно выполнить всю или большую часть работы. Что ещё требуется? Загружать сложнейшее состояние из базы данных, включающее в себя тонну связей? Ну возможно потребуется несколько проекций, а может вообще они не потребуется. Конкретики бы.

skyANAВообщем проекции постепенно перестают быть DTO и начинают пролазить в бизнес-логику :)

Я сторонник эффективного, быстрого и успешного решения задач. Я разделяю архитектуру на слои не просто потому что так где-то написано или так кем-то принято. Я вижу в этом определённые и вполне конкретные преимущества. Проекции в этой архитектуре обычно существуют на стыке слоя доступа к данным и бизнес-логики, при чём сама конфигурация проекции -- это область компетенции бизнес-логики, так как это ей нужны данные, а из слоя доступа к данным всего лишь торчит репозиторий с очень простым обобщённым интерфейсом. Там нет никаких проекций, только чистая модель данных (EDM).

Короче, класс проекции, это DTO. А сама конфигурация проекции -- это бизнес-логика. Таким образом бизнес-логика может отдавать DTO, или иметь свою модель собираемую из DTO, или комбинировать эти техники наиболее эффективным образом.

skyANAТут я имел в виду, что клиентов у бизнес логики может быть K: сайт, десктоп, сервисы, выгрузки какие-то, API.

Так REST-же. Проекции для REST -- то, что доктор прописал. Они же могут дополнительно кешироваться (3 level) по типу. На проекции делаются нормальный IQueryable запросы, что выгодно для OData (да и вообще). Ну круто я считаю.