ネットワークに接続してデータを取得するタイププロバイダーが1つあります。そして、タイププロバイダーメカニズムを介して（私たちが呼ぶフィクション）「静的タイプ」を生成します。
もちろん、私はいつもつながっているとは限りません。衛星接続がダウンしているプライベートジェットで激怒している可能性があります。
（タイププロバイダーからの）タイプを入力として受け取り、その定義をディスクに保存し、後でパンガン島に行く途中で簡単にアクセスできるようにタイプ定義を提供する「オフラインタイププロバイダー」を構築した経験はありますか？パンガン？
TPへのパラメータとして型が許可されていないため、アセンブリ名+型名をオフラインにすることを考えていました。
元のタイプ プロバイダーを拡張して、オンライン モードとオフライン モードの両方で動作するようにすることができます。つまり、成功したスキーマが (プロバイダーが理解できる形式で) ディスクにキャッシュされている場合、プロバイダーはデータ ソースに接続してスキーマを取得しようとします。その後、プロバイダーはディスク上のスキーマ情報を使用して型を公開します。何らかの理由でデータ ソースへの接続が利用できない場合、プロバイダーはキャッシュされたスキーマが存在するかどうかを確認し、存在する場合はそれを使用します。たとえば、標準型プロバイダー (LINQ2SQL または EF) を使用すると、データベースに直接接続できない場合に使用できるスキーマ ファイルを指定できます。
これは、F# 型プロバイダーを記述する際の注意が必要な側面です。しかし、主な問題は、プライベート ジェットで開発していて、タイプ プロバイダーを使用して外部データ ソースにアクセスしている場合、 data にアクセスできないことだと思います。
スキーマ キャッシング- 型プロバイダーが何らかの形式のスキーマ キャッシングをサポートしている場合 (つまり、@desco が言及した LINQ to SQL のような XML ファイルにスキーマを格納することによって)、コードを記述してコンパイルすることはできますが、それでもコードをテストできません。これにより、プライベート ジェットのシナリオではスキーマ キャッシングの有用性が低下すると思います。ただし、スキーマにアクセスできないビルド サーバーでコードをビルドするシナリオでは便利です。
ローカル データ- プライベート ジェットのシナリオでは、作成したコードを実際にテストできるようにするために、おそらくある種のローカル データ (またはサブセット) が必要であり、多くの場合、タイプ プロバイダーをローカル コピー (データベース、 CSV または XML ファイルなど）。
メタプロバイダー- メタプロバイダーを持つというアイデアはかなりクールだと思います - ある程度は機能するはずです - スキーマをキャッシュすることはできますが、おそらくデータをキャッシュすることはできません (おそらくプロパティですが、メソッドは機能しないと思います）。モックするプロバイダーの名前を引数としてメタプロバイダーに渡すだけでよいと思います。何かのようなもの：
type CachedDB =
SchemaCachingProvider<"FSharp.Data.TypeProviders.dll", "SqlDataConnection", "..">
私はこのようなことをする計画を認識していませんが、あなたが始めたなら、FSharpXの人々はそれを見たいと思っていると確信しています:-)。