Web アプリケーションのスケーラビリティを維持するために、データ サービスのみに WCF を使用しています (つまり、アプリケーションの内部で、セッション状態のない非常に無駄のないものなど)。
現在常に渡されているすべてのサービス呼び出しに対して、いくつかの共通プロパティを提供する必要があります。すべての呼び出しに対して単一の要求オブジェクトを持つことは、これらの共通のプロパティを超えて理想的ではありません。残りは非常に多様であり、開発中に頻繁に変更されます。
現時点では、カスタム ヘッダーと clientmessageinspector を使用して値を設定することを検討しています。これは、このシナリオで推奨される最も単純なアプローチですか、それともより良いアプローチがありますか?
もっと詳しく..
以下の赤い点は、正しいアプローチ (またはその方法) がわからない場所です。
送られてくるもの
送信されるデータは単純な ID のセット (userid、clientid などの 3 または 4) です。これらの ID はすべて、セキュリティとパフォーマンスに影響を与えます (場合によっては、どのデータベースに移動するかを決定します)。
また、これを拡張して、より複雑な権限を持たせる予定です - Windows ワーカーには必要ありません。
呼び出し元は、これらがセッション オブジェクトから取得される Web アプリケーションか、これらが手動で入力される Windows サービス ワーカーのいずれかになります。
現在の考え方
理想的には、呼び出し元のワークフローの getinstance は、セッション オブジェクトを使用してこれらのプロパティを自動的に設定するか、Windows サービス呼び出しを使用して手動で設定します (別のコンストラクターですか?)。
次に、これらのパラメーターが、それを呼び出す各関数でコントラクトを構築するために、コード全体で何も考えずに、または一定の参照なしで常に使用できるようにします。現在、多くのサービス コールが発生しています (アプリケーションのスケールや複雑さによるものであり、エンジニアリングの悪さによるものではありません :))。そのため、これが複雑なパーミッションに拡張されているため、自己文書化された方法でルールを適用することが少し難しくなっています。
概念的には、セッションはアプリでこれを処理する場所ですが、サービスは実際には単なるデータ アクセス レイヤー (ビュー マッピング、ページング、およびリポジトリ呼び出しからの最終呼び出しセキュリティ) であるため、そのような繰り返しは必要ありません。または複雑さ、クエリに含める主要なアイデンティティと許可フィールドのみ。
問題
これは、常にこれらのフィールドが必要なため、呼び出しのヘッダーで行うべきことのように感じますが、set と get がエンドポイントとクライアント インターフェイスのライフサイクルのどこに位置する必要があるかについては、少し確信が持てません。それについて間違っていることもうれしいです。