Monochromatique,

LazyLoad работал с первой версии.

Объект принадлежит одному контексту. Можно объект от контекста отцепить и прицепить к другому. Ели связанные загружены - сделать с ними тоже самое. Хотя неясно зачем.

Monochromatique,

Почему старого контекста нет?
Для аттача объекта к контексту нужен только ключ.
А еще можно расширением воспользоваться, которое позволяет dml запросы делать.

hVosttмногие, пришедшие из мира SQL, недоумевают, типа зачем же мне вытаскивать весь объект из базы, если мне нужно всего несколько полей или я собираюсь изменить всего одно-два поля.

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

Все аналогии лживы.

Все ORM c поддержкой Linq позволяют написать проекцию и вытащить ровно столько полей сколько нужно. Тащить все поля все - путь к тормозящему приложению.

Как раз хранимки чаще страдают этим недостатком. Поддерживать 100500 хранимок с одинаковыми или почти одинаковыми предикатами, но разными проекциями на практике никто не хочет, поэтому делают "универсальные" хранимки, которые тянут больше чем необходимо на каждый запрос.

Для изменения данных тоже не нужны целые объекты. В EF (с помощью расширения) и Linq2DB (изкаропки) можно сделать update\insert\delete, не затягивая целый объект.

НО!
Куча инструментов в .NET работает только с объектами - model binding и data binding например. В этом случае change tracking в ORM помогает избавится от тонны кода для меппинга. Change tracking при этом работает только с целыми объектами.

MonochromatiquehVostt,
Если я объекта, допустим order добавлю поле <Guid>clientID, то код, сохраняющий order в context не изменится.
db.DbSet<order>.add(order) ну или что то типа такого.

Ну а если у ордера я создам поле типа <Client>client - то так просто уже не отделаться.
Надо искать этого клиента в контексте - добавлять, если его там нет and so on...

Почему EF не берет это на себя?

А зачем?
Ты можешь создать оба свойства и использовать то, которое удобнее. Или ты пишешь в поле ClientId, а после этого хочешь получить значение из объекта в свойстве Client?
В каком случае такое может понадобиться?

hVosttпозвольте спросить. на сколько тормозящему? вы лично сами замеряли потерю производительности? на сколько она существенна? или это все личные бредовые фантазии, и, как обычно, экономия на спичках?
Более десятка раз значительно оптимизировал приложения просто прописыванием проекций в Linq. Дело не в объеме передаваемых данных, хотя бывает заметно при использовании больших текстовых полей, а в том что с проекциями проще использовать индексы.

hVosttможно, но не нужно. если не нравится работать с объектами, не трогайте LINQ, EF и возвращайтесь к SQL.
Вопрос не в том нравится или нет, а в эффективности программиста и написанного им кода.


hVosttда, можно вытащить столько полей, сколько нужно. но такое может действительно потребоваться, чтобы вытащить соединённый срез данных, или вытащить большую коллекцию чего-то конкретного, и даже в этом случае применяются DTO, и для этого должен быть смысл. но если мы говорим о конкретной записи, то это должен быть целый объект, а не какие-то поля. как их упаковать и передавать, принимать? анонимными объектами? может в DataTable? и много сэкономите? очень сомневаюсь.
Среднее бизнес-приложение имеет соотношение чтения\записи примерно 98\2. Для веб-сайтов разница обычно на порядок. Поэтому оптимизировать запросы имеет смысл всегда. DTO или DataTable не важно, важно какой запрос уйдет в базу.

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


hVosttкороче бред не несите. определённо вы взялись за инструмент, смысла которого до конца ещё не понимаете.
Я понимаю, что искать проблемы в собеседнике проще, чем аргументировать свою точку зрения. Но все таки на профессиональном форуме стоит прибегать к техническим аргументам.