Курдль,

Нужно говорить про версию используемого EF.
EF это entity framework.

А не views framework ))

Курдльentity - это "сущность" и что?

То, что EF это фреймворк для работы с сущностями БД.
А сущность характеризуется наличием идентификатора (уникальный ключ).


КурдльПочему нельзя дать разработчику возможность указать ПК постфактум?

Без проблем, указывайте.


КурдльТочнее возможность такая есть - ручное вмешательство в edmx, после чего он больше не сможет автоматически апдэйтиться из БД

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


КурдльЛадно, я упаковал запрос в процедурину, потерял возможность видеть представление на схеме и выстраивать взаимосвязи с таблицами и т.п.

Многие люди реально теряются при ответе на вопрос: вам шашечки, или ехать?
И в итоге рождаются какие-нибудь костыли.
И виноват какой-нибудь фреймворк :))

КурдльЕсли я выбрал первое - не должен копаться в кишках кода каждый раз, как меняю модель данных.

Вообще-то DB First по сути, это когда у вас есть уже готовая БД и вам нужно для неё быстро сделать работающую систему.

Но некоторые люди по незнанию выбирают такой подход в длительной разработке, и это big mistake.
Комплекс изменений, который вы сделаете в БД очень легко может стать unresolvable , так как EF не обладает искусственным интеллектом, чтобы понять, что на самом деле произошло и как это сопоставить с моделью.

Есть лишь два единственных адекватных способа вести длительную разработку ПО и модели данных с использованием EF: Model First и Code First.

КурдльТак что Вы предлагаете? Оставить представление и дальше edmx править только вручную?

Предлагаю перейти на Model First или Code First. Если это не подходит в силу привычек (очень сильно хочется DDL, до коликах в животе), тогда вам нужен другой ORM и полностью ручное сопровождение. Например, Dapper или LiteDb.

КурдльА может быть создать индексированное представление?

Индексация тут не при чём.

КурдльМне для работы нужны не таблицы или сущности и т.п. Мне нужны НАБОРЫ ДАННЫХ.

Ну и как EF, который работает с сущностями должен определять ваши «наборы данных», как их сопровождать и как с ними работать, как отслеживать изменения и как работать с кешем? Ответ -- никак.

КурдльВ частном случае - результат рекурсивного запроса CTE. EF умеет строить рекурсивные запросы непосредственно к таблицам?

В Code First это делается, например, путём определения класса-сущности для вьюхи и ручной миграцией с SQL. По крайне мере это работает в любых условиях и поведение ожидаемое. :)

Petro123Это делают когда БД есть и ее масштаб - предприятие. Генериррвать не дадут.

Чего это ты мне рассказываешь :)
У нас проекты масштабов предприятия федерального уровня,
ни в одном из них нет БД, которую пилит своими руками в DDL какой-то кадр
всё управляется ПО, никто вообще не имеет никаких прав лезть в БД руками,
только на чтение

и это прекрасно :)

Petro123А о вьюхах и зачем они в ОРМ.

CTE ты без вьюхи в EF не сделаешь, увы
не считая custom sql, но это уже за гранью

Petro123Ведь одна из основных фич ОРМ это смена базы.
Т.е. довод про CTE от лукавого.

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