プラグイン用のデータソースを提供するためのアーキテクチャ

Question

私は、クライアントがタッチスクリーン用のクライアントの場所を示すクライアントサーバーアプリケーションを持っています。目的は、投票、質問からデータを収集し、クライアントとのインタラクティブなタスク（データベース内の検索など）を実行することです。クライアントはWPFアプリケーションで、サーバーからユーザーコントロールをプッシュして表示させることができます。ここまでは順調ですね。

これまで、私はサーバーからクライアントに汎用データソースを公開することができませんでした。私が達成しようとしているのは、クライアントがデータを保存したり（例えば、検索やポーリングの結果）、データソースにデータを照会できるようにするクライアントに「何かに接続されたもの」を供給することです。

クライアントのさまざまなコントロールから収集されたデータは、質問/回答から検索/結果まで大きく異なります。これは私のサーバーを経由したいものです。そのため、各クライアントはデータベースとの独自のデータ接続を保持しません。

私のサーバーのデータベースには、各クライアントのデータ（タイプと列）のメタデータとそのデータを格納するための単純なテーブルを持つ行があります。

このアプローチまたは代替アプローチに関するアイデアはありますか？

Answer 1

どのくらいのデータについて話していますか？

私の最初の提案は、APIとうまく適合しないかもしれませんが、コマンドのデザインパターンを使用してデータを送受信します。これにより、特にプラグインを使用して新しいコマンドをロードできる場合に、通信レイヤーを変更することなく機能を追加または変更できる柔軟性が得られます。しかし、クライアントが作成したプラグインではうまくいくとは考えにくいです。

少量のデータの場合、クライアントにCSVファイルまたはXMLファイルを作成してサーバーに保存し、必要に応じてコピーを要求することは可能でしょうか？これをDataTableまたは類似の構造にロードして、クライアント上でクエリを実行することができます。データに加えられた変更を保存し、クライアントが完了したときにサーバーに戻すことができます。これの利点は、クライアントが必要なデータを指定できることと、クライアントがそのデータをどのように格納したいのかということです。サーバーコンポーネントは気にしません。

大量のデータの場合は...考えません。私は、メタデータテーブルを作成し、それらが記述するテーブルを作成し、その上にクエリフレームワークを構築する経験がありますが、それが最善の解決策であるかどうかは疑問です。ルックアップテーブル、多対多リレーションシップ、カスケードルックアップテーブル、階層などが厄介なものになりがちです。このルートに進む前に必要なデータ要件については慎重に考えます。

データのSQLに制約されていない場合は、RavenDB（または他のNoSQLソリューション）などのデータを格納することを検討することがあります。サーバーに送信するオブジェクトをシリアル化できる限り、それらをデータベースに格納することができます。サーバーにクエリを送信すると問題が発生する可能性があります（ただし、わかりません）。