Petro123,

Коллеги!
Ваша мысль настолько стремительна, что ускользает от меня.
1. Да, возможно мне ближе не DB First, а Model First по вашей классификации.
Я на основании анализа предметной области создаю модель и дальше использую её в качестве основы автоматизации.
2. Выгода от ORM не только в возможности смены БД. Я не хотел бы иметь килотонны слабо контролируемого кода ( в виде DAL, например, всяких коннекторов, ридеров и т.п.). Пусть за меня это делает ORM, а при изменении модели и серверной логики - сама перестраивает "обвязку".
Не понимаю, зачем посылать меня к непосредственной работе с данными.
Мне приходилось работать и с ADO.NET и немало. Особого удовольствия я от этого не получаю.
3. Зачем я использую CTE? А где я должен обрабатывать задачи обхода графов, например? В коде C#?
Перед этим выгрузив все необходимые данные из БД на клиента БД?

Petro123Курдль,
Мы все не поймем что ты жалуешься и что тебе плохо?
hVostt прованговал что тебе нужен CodeFirst.
Я против, т.к. думаю проблема глубже))).

1. Не нужно мне Cose First.
2. И как раз в теме топика - обновление модели силами EF по структуре БД.
3. Я не жалуюсь, а ищу ответ на вопрос: как заставить EF корректно построить модель на основании созданных мной элементов БД (в частности - представлений).
Разве я многого прошу? :D

hVosttКурдль,

Вам нужен Model First.
Можно синхронизировать БД в соответствии с изменениями модели.
Можно добавлять вьюхи и расставлять PK и прочую шелупонь.

Хотя мне ближе Code First, я не люблю чужого волшебства. Только своё :)
Дело в том, что клиентом одной и той же БД могут быть разнообразные приложения, созданные по разнообразным технологиям.
К тому же я не вижу особой разницы, создавать ли сначала ER-диаграмму взаимосвязей сущностей или диаграмму классов.

Petro123hVostt,
Конечно! В вашем магазине овощи свежее чем в соседнем).


Колеги, вы читали, что я написал в посте 21646855 ?
У меня уже было несколько представлений и все они прекрасно сдружились с EF.
Она нашла им какие-то первичные ключи (составные почему-то), я их вручную откорректировал и дальше все Ок!
Но представление, содержащее CTE, она просто исключает из модели (в edmx обставляет символами комментария).
На разных ресурсах типа stackoverflow, сходятся во мнении, что можно edmx поправить руками и все заработает... кроме указанной Petro123 функции 21648289 Т.е. дальше - всё только вручную.

Petro123дык с тобой все понятно.
Чем дальше от законов ОРМ, тем больше у тебя буде вручную.
Я лет 5 назад тоже изгалялся с составными ключами без PK.
Потом плюнул.
И чего я экономил спрашивается? Спички?
Я не изгалялся с составными РК. Все РК в таблицах по-честному есть. Как объявить РК во вьюхе я не знаю :(
Но EF при выполнении функции Update model from database по каким-то своим соображениям делает составной РК из всех не nullable полей.

Petro123Курдль,
Сгенерируй во вьюхе первичный. Может прокатит.

Как?
(СУБД MS SQL Server 2014)

Petro123,
stackoverflow

Petro123у меня в постгри есть row_number().
Спроси ветке бд.
Представление, которое я пытаюсь вставить в модель, имеет поле, которое желехобетонно является РК.
Т.е. мне не нужно исхитряться, чтобы добыть РК каким-то сторонним способом, типа row_number.
Но я не могу объяснить EF, что это поле - РК :(