Shocker.Pro,

Рекомендую забыть про AsNoTracking. Чтобы получать сущности только для чтения, просто воспользуйся отражением, и будет счастье:




Вот и всё. Плюсы -- не надо ковырять EF и его потроха, независимость от источника данных (в целом, это вообще может быть не DbContext, а простой List, что очень удобно для юнит-тестов, или вообще что-то другое, лишь поддерживало IQueryable), ты получаешь только те данные, что тебе надо (именно тот набор полей) и не можешь ничего изменить случайно ни при каких обстоятельствах, т.е. без всяких допущений, что там дескать должен работать AsNoTracking.

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

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

Потому что интерфейс реализован явно (explicit) (т.е. требуется приведение к интерфейсу).

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

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

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

Я стараюсь избегать нативной реализации М:М, предлагаемой EF. Вместо этого я сам определяю таблицу двухсторонней связи, это хорошо тем, что контроля больше, в связь можно добавить атрибуты (хотя бы даже время установки связи и кем она сделана), и не надо так морочиться, можно использовать чистые Id, без свистоплясок. Но если такой возможности нет, то как я сказал выше.

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

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




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

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

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

Но за всё надо платить, естественно. Хотя разницы нет, если ты модернизируешь сущность заказа, это отразится во всех слоях. Когда возникает потребность сократить монотонный труд, можно написать кодогенерацию. В любом случае, офигенный профит тут в строгой типизиации, и в оптимальности запросов/данных.

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

Да, конечно. Автомаппер молодцом, пока проблем с ним небыло )

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

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

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

В смысле, динамическую проекцию? Выбрать разные наборы полей по условию? Или как?

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

Произвольный набор полей, это что? Как раз таки Project().To() заранее знает набор полей, так как при компиляции тип определён, набор свойств типа известен, кроме того должен быть определён маппинг для типа.

Или ты имеешь в виду некий нетипизированный датасет?

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

либо new {}, либо new MyPOCO {}. Сам по себе EF плоскую проекцию не создаёт, а вот AutoMapper умеет, если придерживаться соглашений .

Или ты имеешь в виду нечто типа SELECT *, и получить набор полей, имеющихся в БД? Просто не понимаю, куда это должно замаппиться, типа анонимный класс, созданный динамически на основе полученного набора? Не уверен, что в этом есть смысл, а на деле не помню, чтобы кто-то такое поддерживал. Технически для подобного результата надо будет мутить с рефлекшеном и эмитить код.

MonochromatiquehVosttShocker.Pro,

Рекомендую забыть про AsNoTracking. Чтобы получать сущности только для чтения, просто воспользуйся отражением, и будет счастье:

У отражения как бы другое значение. То, что ты описал - это проецирование, нет?

Ты прав, я имел в виду проекцию.

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

В рантайме, да. Но тип результата всё равно известен на этапе компиляции, даже если он анонимный.

На счёт того, как это реализовано, можно посмотреть в исходниках AutoMapper, как он строит дерево выражений. Учитывай ещё то, что AutoMapper использует конфигурацию, задаваемую в CreateMap (а именно, с помощью инструкции MapFrom).

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

По сути, разбирает дерево выражений, затем рисует запрос. Для определения набора полей, важен тип результата (анонимный, или POCO).

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

Вообще, иногда я и делаю такую вьюшку в БД, затем маплю её к POCO в EF, чтобы использовать в различных JOIN-ах и выборках. Самое частое, это оформленные в виде View, CTE запросы, которые ни LINQ, ни EF не поддерживают ни в каком виде.

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

Т.е. вместо наследования, комбинирование? Представляешь, как это можно выразить на C#? Я нет, ведь C# не поддерживает множественное наследования, а скомбинировать два типа, чтобы получить один с полями из обоих типов — это возможно только для интерфейсов, но EF работает с классами.

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

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

MonochromatiqueВсё, что тут насоветовали от AsNoTracking до создания новых объектов - по сути сводится к одному - к уничтожению контекста.

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

MonochromatiqueСущность, которую вы изменяете на форме/методе/wherever - может уже давно не принадлежать к контекту, так как встретила на своем пути automapper какой-нибудь, или простую проекцию через select - и что? Гоняться с отладчиком по всему приложению, выясняя - где сущность выпала из контекста? Страсть то какая.

На форме не меняется никакая сущность, а данные вью модели. Поэтому эти рассуждения не в кассу. Кого ты гонять с отладчиком собрался? ))

MonochromatiqueЭто уместно в любых рамках, ибо в контексте DI любой модуль может считаться клиентом.

Это слишком абстрактно.

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

Чтобы не заставлять прикладного программиста постоянно зырить в стеклянный шар и гадать на кофейной гуще, не отдавай ему экземпляры модели EF. Используй DTO и проекции. Тогда и страховка будет 100%.

MonochromatiqueА до вьюмодели еще дорасти надо. Для многих тут MVVM - однозначно читается как WPF-ная придурь.

Так а чо там расти, элементарный же паттерн.

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

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

MonochromatiqueДругие сценарии его (контекста) использования - нестабильны и опасны.

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

Shocker.ProАвтомаппер, в свою очередь, с SQL не работает, очевидно, это не его забота. Поэтому мне не очень понятно, что ты имеешь ввиду под "рисует запрос". Вполне возможно, это из-за того, что я не понимаю, какую роль в данном случае играет IQueryable.

Автомаппер строит дерево выражений, основываясь на типе, соглашениях и конфигурации. А EF наоборот, парсит это дерево, преобразуя его в SQL. Набор полей в запросе зависит исключительно от типа возвращаемых данных в IQueryable<T>. IQueryable это «запрос» в мире .NET, и он содержит всю необходимую информацию для создания запроса SQL.

Т.е. набор полей, это набор свойств выходного типа, не важно DTO это или анонимный класс, для EF не имеет значения, он смотрит на состав полей и выражений в дереве.

Shocker.Proя правильно понял, что ты вынужден создавать навигационное свойство для цели такого джойна?

Вовсе не обязательно. Хотя навигационные поля я делаю, но можно обойтись и без них, приджойнить, например по ID, EF прекрасно поймёт.


Shocker.ProГм, нет, пожалуй, я опять возвращаюсь к правой части присваивания. Я могу сделать такую проекцию "на лету":
(n => new { n, n.Creator.Organization.Name, n.Changer.Surname })
EF выберет сущность n целиком и еще два связанных поля. Так вот, я ищу способ, чтобы не расписывать каждый раз "n.Creator.Organization.Name, n.Changer.Surname" (допустим, это типовая выборка, допустим, там несколько полей) а каким-то образом использовать повторный код.

К сожалению нельзя совмещать отражения Автомаппера и отражения, создаваемые вручную анонимными типами. Т.е. Project().To() не совместимо с Select(p => new {...}). Т.е. либо создаешь все отражения в конфигурации Автомаппера, либо выбираешь все поля буквально по свойствам вручную. Я просто не встречал такого и не имел подобного опыта. Поэтому использую в основном чисто проекции автомаппера (который, кстати, прекрасно понимает вложенные проекции), либо реже проекции через анонимный тип (new { ... }), в зависимости от ситуации.