Cześć,
Czy ktoś z Was ma może pojęcie czy można dynamicznie per użytkownik lub per aplikacja generować model EDM dla odata?
Chciałbym osiągnąć w aplikacji WWW możliwość rozszerzania dostępnych kolumn w tabelach (gridach) bez deployowania nowych wersji aplikacji.
A dokładniej, aktualnie mam w SqlServer zdefiniowany widok zmaterializowany do którego mam wygenerowany obiekt podpięty do EF Core i wystawioną metodę Get która działa z Odata (paginacja, filtrowanie, sortowanie itp.), chciałbym teraz mieć możliwość dodania do WWW do tabeli nowej kolumny bez konieczności deployowania nowej wersji aplikacji z kodów backendu i frontendu. W grę wchodzą tylko zmiany po stronie SQL czyli rozszerzenie widoku o kolejną kolumnę. Dostępne, widoczne dla użytkownika kolumny były by zawarte w jakiejś konfiguracji po stronie DB. Czy jestem w stanie coś takiego osiągnąć?
Czyli mam klienta, który w aplikacji widzi kolumny A, B, C. Ale stwierdza, że chciały jeszcze widzieć jakąś jedną daną dodatkowo, wtedy administrator dodaje nową kolumnę do widoku po stronie SQL oraz dokłada ją do konfiguracji konta użytkownika, żeby frontend był w stanie dodać ją dynamicznie do grida. Ale całe clou w tym jak to uzyskać żeby z automatu działało pobieranie danych filtrowanie itp po stronie Odata bez dodawania do kodów obsługi nowej kolumny.
Wszystko ok, ale jak masz zamiar obsłużyć kwestię encji? Do modelu EDM trzeba przekazać typ, EF Core też operuje na typach. Jeśli zmienisz w SQL to obawiam się, że się nie zmieni w EF 
No właśnie stąd pytanie czy można to jakoś osiągnąć :)
No to pytanie jest źle zadane, ponieważ model EDM nie ma nic wspólnego z EF Core i encjami, bo z Google wynika, że się da. A odpowiadając na faktycznie pytanie - nie jest to wartę twojego czasu. Moim zdaniem leżysz na samym projektowaniu całego przedsięwzięcia, bo jeśli od góry zakładasz, że będziesz dodawać kolumny na tyle często, że przekompilowanie całej aplikacji jest dla ciebie problemem to coś jest nie tak...
EDIT
Po wypowiedzi @SkrzydlatyWąż zrozumiałem o co biega z tymi kolumnami. Stwierdzam, że chyba nie rozumiesz procedury jaka zachodzi w wyborze kolumn na froncie, a już tym bardziej korzystając z OData.
EF operuje na zdefiniowanych typach, nawet budowanie DbContextu w runtime tutaj nie pomoże. Prościej byłoby chyba budować SQLe bazując na danych z OData.
Pytanie, czy na pewno chcesz pozwolić użytkownikowi na modyfikację bazy? Czy zbiór kolumn może jednak jest stały, a część będzie niedostępna? Albo w ogóle zmienić podejście i opisywać obiekty zestawem atrybut -> wartość bez modyfikowania tabel w SQLu. Albo spróbować z kolumnami JSON albo nawet z Mongo, jeśli chcesz mieć elastyczne struktury :D
Użytkownik / klient nie będzie miał dostępu do DB, a jedynie wyznaczony opiekun klienta - administrator, jest jeden system do niego ma być jedna aplikacja, ale będzie wiele klientów, a później każdy chce widzieć w aplikacji co innego. Więc buildowanie dla każdego klienta osobnej wersji aplikacji odpada bo kto to będzie później utrzymywał :) A znowu tworzenie widoków z 50 kolumnami, gdzie na danym serwerze będzie np. 3 klientów korzystających z 1/5 kolumn też jest słabe.
Użytkownik / klient nie będzie miał dostępu do DB
Skoro może sobie zażyczyć jakąkolwiek kolumnę chce to to nie wygląda mi jakby nie miał dostępu. Może nie bezpośrednio ale pośrednio może wyciągnąć wszystko jak będzie chciał.
Na tę chwilę jedynym rozwiązaniem jest zmienić ORMa na Dappera i wykorzystać dynamic.
How to return dynamic types List<dynamic> with Dapper ORM
Dodatkowo przykład z DapperRow