skyANAМагии нет, есть ModelBinder

ModelBinder здесь не подойдёт, так как решает совсем другие задачи.

MonochromatiqueВопрос №1
Нет ли в ASP MVC каких-то телодвижений, которые преlпринимает сама плаnформа и превращает полуфабрикат объекта с распарсенной формы в полноценный объект, который осталось только запихнуть в контекст? То есть объект заявка с уже прилепленными к ней объектами вида заявка_бренд?

Не знаю, что ты там понимаешь под полуфабрикатом объекта, но суть в следующем:

Порядок отображения данных (Display):

Controller/Action → ViewModel → View

Порядок получение данных (Edit):

View → ModelBinder → ViewModel → Controller/Action


Полученные данные из View с помощью ModelBinder преобразуются в типизированную ViewModel и передаются действию контроллера. ViewModel, хранящий коллекцию brandIds не является никаким «полуфабрикатом», так всего лишь представляет данные, полученные с формы.

Варианты реализации действия контроллера после получения данных:

1. «Толстый вариант» контроллера
получить объект заявки из контекста

пройтись по списку брендов в заявке и сравнить их ID с полученным списком во ViewModel

удалить из заявки отсутствующие бренды в полученном списке во ViewModel

добавить в заявку отсутствующие бренды в заявке, для этого по ID надо получить объект бренда из контекста и добавить в коллекцию брендов заявки

2. Правильный «тонкий» вариант контроллера

преобразовать (например, с помощью маппинга) объект ViewModel в DTO для бизнес-логики

передать объект DTO в метод обновления записи заявки сервиса бизнес-логики

Ещё раз, ViewModel это вообще не бизнес-объект. Не фабрикат, недофабрикат или полуфабрикат. Это просто типизированные данные, полученные, например, из формы. Как эти данные засунуть в свою бизнес-логику, этим вопросом ASP.NET MVC не занимается, ничего для этого не предлагает, да и не должно.

Проблема, с которой некоторые сталкиваются состоит в том, что они зачем-то используют в качестве ViewModel-ей классы контекста EF. Это всегда оборачивается жопой. Всегда. Не стоит так делать никогда.

MonochromatiqueЭто разумное количество кода?

Если всех разработчиков (или тебя, если ты один) такое устраивает и это работает, то ок. Но я бы подобное не стал бы сопровождать в принципе.

MonochromatiqueПод полуфабрикатом я имел ввиду следующее:
Объект, загруженный via LINQ с использованием INCLUDE для полей типа коллекции. Это я считаю как полноценный объект.

Если объект, полученный с формы _нельзя_ получить СРАЗУ в виде описанному выше (через волшебные conventions и прочую магию) - то я это считаю полуфабрикатом.

Но теперь понятно, что "подчиненные объекты" создаются без участия владельца объекта.
Это привычка с 1С осталась - там в табличную часть справочника НЕЛЬЗЯ записать что-либо НЕ ЧЕРЕЗ объект владелец.
В EF я думал, будет что-то похожее, но ошибся.

Include в EF этой убогий костыль, обсуждалось уже.

Для доступа к навигационным свойствам объекта используется «ленивая загрузка» (lazy loading), с помощью ключевого слова virtual в объявлении навигационных свойств. Include не нужен. Для запроса больших объёмов коллекций лучше использовать отражения.

MonochromatiqueЯ хочу как правильно. Почему не стал бы сопровождать, да еще и в принципе?

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

MonochromatiqueХм. То есть объект client_request_brands_car не нужен? EF этот класс сама создаст? И работать тогда придётся ТОЛЬКО через коллекцию объекта client_request?

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

MonochromatiquehVostt Для доступа к навигационным свойствам объекта используется «ленивая загрузка» (lazy loading).

А как она лениво загрузится, если контекста уже давно нет? Magic?

А куда он делся?

MonochromatiqueLost in space. POCO он на то и POCO - хочу обратиться к свойству - изволь вспомнить про контекст. Не понимаю.

Вообще-то EF возвращает объект прокси-класса, если специально не запретить ему этого. А в веб-приложении обычно делают контекст живым в рамках запроса, этого вполне хватает. Ну да ладно. Я просто высказал свои соображения на эту тему.

MonochromatiqueМы про EF Code First говорим? Какой объект прокси класса?

Да хоть Code Zero

https://msdn.microsoft.com/ru-ru/library/vstudio/dd456853(v=vs.100).aspx

Cоздание прокси-объекта

Чтобы платформа Entity Framework отслеживала изменения в классах POCO по мере их внесения и чтобы обеспечить поддержку отложенной загрузки связанных объектов, классы POCO должны соответствовать требованиям, описанным в разделе Требования к созданию прокси-сущностей POCO (платформа Entity Framework).

Если создание прокси-объектов для сущностей POCO разрешено, то изменения, вносимые в граф и значения свойств объектов, отслеживаются платформой Entity Framework автоматически по мере их внесения. Сведения о параметрах отслеживания изменений с использованием и без использования прокси-объектов см. в разделе Отслеживание изменений в сущностях POCO (платформа Entity Framework).

Можно использовать комбинацию сущностей POCO и прокси-объектов сущностей. Чтобы отключить создание прокси-объектов, установите свойство ProxyCreationEnabled в значение false для экземпляра ObjectContextOptions, возвращенного свойством ContextOptions объекта ObjectContext: