баз лайтер,

Делать проекцию. Гугли в сторону OData + AutoMapper, например

http://codethug.com/2015/02/13/web-api-deep-dive-dto-transformations-and-automapper-part-5-of-6/

В кратце, ты делаешь для своего продукт проекцию ProductDto, в которой твоя проперти превращается из вложенного объекта в примитивное свойство. Объяснять на пальцах долго, лучше погугли, посмотри примеры, навалом их. Если что непонятно, спрашивай.

СмузиЯ бы не назвал это задачкой из учебника. Это обход модели. Вот тут я показывал, как можно трачиться по кастомному свойству http://codearticles.ru/articles/2736

Какой глупый и вредный пример.

Есть нормальные проекции, максимально эффективные и простые, позволяют использовать всю мощь запросов через проекции, следовательно, кладутся на OData, как влитые.

Зачем вот такой фигнёй заниматься, как у тебя в примере?

СмузиhVostt, смотри, в чём различие. Я привел валидный пример, который 100% работает. Ты привел какой-то мусор с маппингами, никакой конкретики по существу. О чем с тобой можно говорить?

Ключевое различие в том, что ты не понимаешь в чём разница чистой выборки и SELECT N+1, в решении которое ты привёл. Маппить коллекции, имея возможность просто и удобно проецировать в DTO, имея готовый инструмент, это идиотизм. Уж извини. Идиотизм. Точка.

СмузиИменно это и нужно в исходной задаче :) "хочется видеть property, а не вложенный объект"

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

Ты «нахлебался» с проекциями, потому что так и не научился ими пользоваться. Кури ProjectTo(), это одним словом красота, генерятся офигенно быстрые SQL, ничего лишнего, поверх проекций легко фигачатся запросы, как к объектам контекста напрямую.

СмузиТут не удержался, чтобы эту глупость не прокомментировать. Читай про $expand odata filter, одним запросом выбирается то, что нужно и намапливается на то, что нужно.

Экспанд тебе не поможет, если ты хочешь инкапсулировать подзапрос, например отсечь вложенные удалённые записи, или не проходящие по безопасности, отдавать кишки реальной модели данных в БД никто в здравом уме никогда не будет.

Смузи,




Всё, что для клиента, лишнее отсекается в конфигурации проекции. Если требуется протащить безопасность, передаётся параметрами внутрь подзапроса. В результате имеем очень быстрый и эффективный запрос, без SELECT N+1.

СмузиhVosttотсечь вложенные удалённые записи
ODataQueryOptions

Т.е. ты хочешь пописать много кода, который просто можно было бы не писать и получить гораздо более эффективный результат? Ахахах.. Тем более QueryOptions также применим и для проекций, такскзать в old school стиле.


СмузиТретий раз прошу выкатить полностью валидный код, но снова какие-то огрызки кода.

Приведённого мною кода вполне достаточно для понимания. Если что-то не понятно, задай вопрос.

баз лайтерспасибо за конструктивную дискуссию, пилю DTO для всех 100500 корневых сущностей, и настраиваю мэппинги в обе стороны



Очень не удобный и плохой подход. Используй:

1) профили и автоматическое сканирование в рамках модуля

https://github.com/AutoMapper/AutoMapper/wiki/Configuration

2) ReverseMap

СмузиhVosttТ.е. ты хочешь пописать много кода, который просто можно было бы не писать и получить гораздо более эффективный результат? Ахахах.. Тем более QueryOptions также применим и для проекций, такскзать в old school стиле.
Не важно какой стиль, я говорю о рабочих решениях. Ниже варианты разбора. Один из них транслирует IQueryable для аксапты (нативный коннектор, который не поддерживает в коробке IQueryable).
http://codearticles.ru/articles/2486
http://codearticles.ru/articles/2472
http://codearticles.ru/articles/2522

hVosttПриведённого мною кода вполне достаточно для понимания.
Всё с тобой понятно. Когда дорастешь до рабочего кода, приходи - поговорим. А пока теоретики идут в лес.

Ну и чё ты накидал какого-то барахла тут? Я критиковал очень конкретный пример, который ты привёл по ссылке codearticles.ru/articles/2736, я сказал в чём конкретно проблема этого примера, почему он вредный. Могу повторить ещё раз: SELECT N+1, не целевое наследование (добавление в иерархию классов Entity, чтобы добавить поле — да ты точно упоролся!).

Не понимаю чё ты упираешься? С чем не согласен? Сам же упоминал про Automapper IQueryable Extensions, т.е. прекрасно знаешь о чём я говорю, но только откуда столько пренебрежения? Любишь строчить код? Ну это же твой фетишь, писать как можно больше кода. Пускай новички учатся решать свои задачи наименьшим количеством строк кода с максимальной эффективностью и гибкостью. Ты же можешь колотить по клавиатуре дальше

hVostt(добавление в иерархию классов Entity, чтобы добавить поле — да ты точно упоролся!)

* поле чисто для передачи данных клиенту (по сути функциональность DTO).

СмузиЗадачи у автора такой не стояло. Критиковать можно даже Библию, только какое это имеет отношение к сабжу.

Ты привёл очень плохое решение. Я пояснил почему. К сабжу оно имеет прямое отношение, ты даёшь вредные советы. То, что они при этом рабочие — не оправдание.

СмузиЯ ответил, проблема решается трансляцией IQueryable из ODataQueryOptions. Да, кода больше, но это 100% рабочее решение. Его плюс, что оно применяется в там, где никакими IQueryable и не пахнет. Я могу сам сконструировать любой запрос с фильтрами и сортировками (например, X++), который полезет в совсем другой движок и вытащит данные. Понимаешь, о чем речь?

Плюс, про который ты говоришь, очевиден только в единичных случаях. Я согласен, что такие бывают, они обязательно будут, но это не значит, что из-за них надо теперь всегда решать задачу сложно, когда в большинстве случаев её решить можно просто и гораздо меньшими усилиями. Большая часть покрывается проекциями в DTO, при чём довольно сложными и с параметризованными подзапросами, которые Automapper делать умеет.


СмузиЯ не упираюсь. Я прошу привести годный пример, а не фантазировать о теориях. Ты привести такой пример не можешь. Собственно, не вижу смысла дальше продолжать с тобой эту тему.




Ещё больше упростил пример. Что тебе здесь непонятно?

СмузиhVostt, всё что я сказал выше - повторил несколько раз. Твоя квалификация под вопросом, в дальнейшем обсуждении темы не вижу смысла.

Хорошая попытка, МСУ, но нет Спрашиваю, что тебе не понятно в приведённом примере, чего не хватает, ты несёшь какой-то больной бред насчёт квалификации. Смысла ты не видишь, потому что сам уже не знаешь за что зацепиться, и что сказать хотел

Не пей так больше, до НГ ещё далеко.

СмузиЯ уже отвечал, мне ничего непонятно. Нужна модель, маппинги, нужен реальный рабочий пример, а не огрызки. Такой пример, какие всегда даю я и некоторые другие участники форумов . Где взял код, вставил в одата сервис и заработало. Но ты не в состоянии привести рабочий вариант.

Модель, маппинги, реальные рабочие примеры — этого всего по теме хоть одним местом жуй. Не моя проблема, что ты не в состоянии нагуглить полноценных рабочих примеров. Пример, который я привёл отлично поясняет мою мысль, если бы у тебя были вопросы, ты бы их задал, были бы замечания, ты бы сказал.

баз лайтерReverseMap

Неправильный подход, либо Update, либо Create, в теминах REST это или PUT или POST, как совершенно отдельные операции.

Делать Update-OR-Create в одном методе POST на мой взгляд — ошибка проектирования, с которой придётся не раз поиметь много-много проблем. То, что на первый взгляд выглядит упрощением, выльется в каскадный ворох проблем.

Никогда не рекомендую так делать. Создание это создание, изменение это изменение. У них может быть совершенно разная логика и скорее всего со временем будет.