こんにちは。
一応実現できる回答はありますが、正しく動く保証は一切できません。ご了承下さい。
C# と EF の知識がある程度あることを前提にします。
まず、構造が等しい各テーブルの構造のみを抽象クラスとして定義します。
csharp
1public abstract class TableXXModel
2{
3 public int Id { get; set; }
4
5 public string Name { get; set; }
6}
各テーブルのモデル定義を空にし、先のモデルを継承して定義します。
DbSet<T> の型定義には以下の具体型を使用します。
csharp
1public class Table0 : TableXXModel
2{
3 // keep empty
4}
5
6public class Table1 : TableXXModel
7{
8 // keep empty
9}
10
11...
テーブル番号を元に各テーブルを表す DbSet<T> を取得し、Cast メソッドで IQueryable<TableXXModel> にアップキャストし、変数に格納します。
csharp
1var table = TableNo switch
2{
3 0 => DbContext.Table0.Cast<TableXXModel>(),
4 1 => DbContext.Table1.Cast<TableXXModel>(),
5 2 => DbContext.Table2.Cast<TableXXModel>(),
6 _ => throw ...,
7};
8
取得した table に対してクエリを書けます。
csharp
1var query = table.Select(o => o.id);
以下は注意です。
アノテーションがどのように作用するかは一切検証していません。
各カラムの注釈は抽象クラスへ、テーブル名は継承クラスへ付ければ動くかもしれませんし、動かないかもしれません。
FluentAPI を使った方が確実です。そうしても正しく動くかは不明です。
奇妙なクエリやパフォーマンス的に問題があるクエリが発行される可能性はあります。
見た限りでは問題なさそうでしたが、まともでないことをしている以上どうなっても不思議ではないです。
今まで自動生成を利用していた場合は、今後は機能しないので手動で全て管理して下さい。
EF はメタプログラミングの塊なので、この方法でちゃんと動いていてもある日突然動かなくなることも考えられます。
同じ構造の複数テーブルを使い分けるというのが謎なので、データベース側を修正して一つのテーブルにまとめることも検討したほうが良いです。
パフォーマンスの観点で水平分割している場合が考えられますが、その場合テーブル名でアクセス先を決めることはしないでしょう。