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 { ... }), в зависимости от ситуации.