netivanНельзя в одном "запросе" обращаться к разным контекстам
Это, к сожалению, ограничение ORM. В таких случаях приходят на помощь вьюхи, табличные функции или хранимые процедуры. Ничего не поделать с этим злом...
Но я бы лучше захардкодил запрос в своём репозитории (или что там у тебя) с маппингом на класс. Что-то типа такого: http://codearticles.ru/Home/ArticleView/2147

Lord British, стрёмный недокументированный способ. Ковыряния в XML edmx файлов к добру не приведут, завтра выйдет новый релиз EF с измененной структурой XML и после какого-нибудь Run Custom Tool всё упадет нафик.
Я бы так не делал. Да и завязываться на синонимы (чисто сиквельная фича) я не стал бы. Уж лучше вьюху написать.

Lord BritishEDMX документирован (как минимум storage, concept, mapping). Даже книжки есть где он разжеван Bochicchio Daniele - EF 4.
Не совсем всё так хорошо, как ты думаешь. EDMX рекомендуется майкрософтом модифицировать с помощью дизайнера. Да, конечно, они допускают возможность вносить правки руками, но только для неподдерживаемого функционала самого дизайнера (таких фич немного).

http://msdn.microsoft.com/ru-ru/library/cc982042(VS.100).aspx EDMX-файл — это XML файл, определяющий концептуальную модель, режим хранения и их сопоставление. Кроме того, EDMX-файл содержит сведения, используемые конструктором моделей EDM ADO.NET (конструктор сущностей) для подготовки модели к просмотру в графическом режиме. Рекомендуется производить создание EDMX-файла с помощью мастера моделей EDM. Дополнительные сведения см. в разделе Как создать новый EDMX-файл (средства модели EDM).


То есть тебе четко черным по-белому говорится в документации, что, товарищ, не лезь руками в EDMX. При этом они соглашаются, что существуют сценарии, при которых придется изменять EDMX-файл вручную, там 5 сценариев, которые пока в дизайнере поленились сделать.

Lord BritishЭто примерно также как XML-маппинг в хибере.
Не путай божий дар с яичницей. В хибере нет дизайнера, и кроме как писать маппинги на XML (*.hbm файлы) - других вариантов нет. И только через несколько лет придумали Fluent-маппинги, потому что людям реально наста..ело ковыряться в этом XML, чуток ошибся или дрогнула рука - вся модель порушилась. Сиди потом выноси моск, где там оно что упало. Позже, конечно, был выпущен дизайнер, но он сторонний и платный - есть далеко не у каждого. Вот такая картина маслом.

P.S. Поэтому-таки я бы настоятельно не стал ориентироваться на ручное вмешательство в код, да еще и таким жестким способом, как мерж EDMX файлов через какие-то там магические манипуляции с нодами XML документа. Есть дизайнер и точка. Иначе - CodeFirst. Всё остальное от лукавого.

Lord BritishEntityFramework'у совершенно не нужен в рантайме *.edmx. Сам edmx создан исключительно для поддержки со стороны дизайнера студии.
Я и не утверждал про рантайм, модель в DbFirst должна создаваться из дизайнера и только из него. Кому сейчас нужны ручные ковыряния в унылом xml?

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

Lord BritishВероятно, в этом контексте можно понимать фразу. В любом случае она требует уточнения. Я так понимаю публикация документации CSDL, SSDL,MSL аргумент в сторону - публичное, документированное.
Насчет документирования согласен, погорячился в начале - спецификации есть. Но заморачивать разработчика ими я бы не стал - кому нужен этот геморой со всеми вытекающими. Разработчик пусть сосредотачивается на прикладной задаче, а не на ковыряниях в xml, в котором легко ошибиться. Ручные xml маппинги - зло.

Lord BritishВ этом случае (использование CodeFirst API) синонимы тоже рулят. И это, вообще говоря, не только MS SQL фича, как минимум еще Oracle умеет. Ну, а там где не умеет, можно вьюху написать.
О том и речь, лучше вьюху.

Lord BritishPS. Религиозные вопросы я считаю. Автор все равно сделает согласно своему чутью, так что. :)
Ок, я высказал чисто своё мне по вопросу :)