Гуглил, но, видимо, не то или не так.

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

Есть ли в EF что-то в таком духе?

МСУТолько AsNoTracking для всего сета.Собственно, мне и нужно для сета.

Я правильно понял, что если я сделаю MySet.AsNoTracking().SingleOrDefault(....), полученная единственная сущность также не будет отслеживаться контекстом?

Я правильно понял, что я не получу исключения при сохранении, просто изменения таких сущностей будут проигнорированы?

Есть ли какие-то неприятные побочные явления у этого метода (ну типа, материализация, производительность и т.п.)?

Спасибо.

спасибо, гляну

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


Пока в контексте не было NoTracking объектов, этот код работал, когда они там стали появляться, метод Entries генерит исключение:The object in the ' мой_notracking_тип ' role cannot be automatically added to the context because it was retrieved using the NoTracking merge option. Explicitly attach the entity to the ObjectContext before defining the relationship.не догоняю, что мне с этим сделать, как получить список измененных сущностей

Разобрался через ObjectContext.ObjectStateManager.GetObjectStateEntries

Только нифига не понял, мой контекст наследует DbContext-у
DbContext реализует IObjectContextAdapter, таким образом должен иметь свойство ObjectContext

Однако, Intellisense мне его не выдает, пока я явно не приведу db к IObjectContextAdapter, компиляция тоже не проходит без приведения, почему так?

hVostt,
Доводы ясны, но есть другие соображения, о них позже.

Подскажи тогда плиз, как правильно сделать.
У сущности есть навигационное свойство "многие-ко-многим", в виде virtual List<MyEntityType>

При создании/редактировании экземпляра сущности, у меня есть коллекция id-шников внешнего ключа. Как мне правильно заполнить это свойство?

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

hVosttи не надо так морочитьсяНу, хорошо, у тебя есть лишняя сущность - связка.
А => ММ <= Б
Таким образом, при перезаписи сущности А тебе не надо дергать сущности Б.
Нужно грохнуть все сущности ММ, связанные с А, создать новую коллекцию сущностей ММ (ссылка на Б прописывается через ММ.Б_Id)
Как вариант, грохнуть только удаленные сущности ММ, неизменившиеся подгрузить и добавить только новые.

Ну и обслуживать эти связки их нужно, создавать, управлять....

Вроде как, мороки больше. Опять же, ты же вроде сторонник по максимуму использовать возможности EF ))

hVosttпросто воспользуйся отражениемА вот скажи, как ты поступаешь, когда членов много? Используешь какой-то кодогенератор? А при модернизации сущности?

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

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

ЗЫ: Дополнительный вопрос - в твоем примере с автомаппером - сработает ли оптимизация, и данные разных сущностей из БД будут получены одним запросом с join-ом?

В развитие темы проекций.

А как создать динамическую проекцию (чтобы EF ее нормально понял и оттранслировал)?

Надо мутить с деревьями выражений или копать в сторону динамически создаваемого типа через рефлексию? Или есть какой-то более простой способ?

Да, как-то нечетко сформулировал. Пожалуй, что вопрос даже на два пересекающихся распадается:

1) Как в рантайме создать проекцию из произвольного набора полей. Например автомаппер с его Project().To() не знает заранее набор полей для проекции, он его формирует на основе созданной в рантайме карты динамически - как?

2) Select(n => new { ... })
какие конструкции можно подсовывать в EF вместо "new { ... }" или "new MyPOCO() {...}", чтобы EF составил плоскую проекцию и выбрал все одним запросом?

hVosttКак раз таки Project().To() заранее знает набор полей, так как при компиляции тип определёнПри компиляции известно, какой набор полей будет на выходе, но неизвестно, какие поля будут затребованы из БД.

Допустим я в DTO-классе прописал поле CreatorName, которое автомаппером будет преобразовано как свойство Name у навигационного свойства Creator. При этом карту преобразования он ведь составляет в рантайме. То есть именно в рантайме он должен сообщить EF-у, какие поля из объектов и навигационных свойств ему нужны. Вот этот механизм я и пытаюсь понять.

=======================

Я, в общем-то, хочу разобраться, как EF работает с проекцией, чтобы у себя обобщить некоторые вещи...

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

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

То есть, к примеру, у меня есть базовый DTO класс, но, используя его для проекции, я хочу в конкретных случаях присоединить еще пару полей (из связанных таблиц в том числе) и при этом не городить ветвистые деревья DTO-классов.