2

同じサービスのメソッドにアクセスする 2 つのクライアント アプリ (Web アプリとエージェント アプリ) がありますが、要件が少し異なります。私のチームは、すべてのメソッドに ApplicationType パラメーターを渡すことで、サービス側の動作を制御したいと考えています。これは、基本的に、呼び出し元のクライアント アプリケーションの名前を含む列挙型です。これは、データベース ルックアップのキーとして使用され、サービスを構成します。クライアント固有のオプション。

サービスがどのクライアントがそれを呼び出しているかを実際に認識する必要があるとは思わないので、これについての何かが私を不安にさせます。メソッド呼び出しを介してオプションの負荷を動的に渡すよりも、この方法で実行する方が簡単だと言われています。

クライアントアプリケーションがサービスに自分が誰であるかを伝えることに何か問題がありますか? それとも、構成キーを渡す場合とパラメーター化されたオプションのセットを渡す場合に違いはありませんか?

私が目にする差し迫った問題の 1 つは、サード パーティが実行する別のクライアントにサービスを公開した場合、それらの構成設定をローカルで維持する必要があることです。現時点では両方のクライアント アプリを所有しているため、それほど問題にはなりません。

どのようにしますか？

4

4 に答える 4

3

階層化されたソリューションでは、レイヤーを常にタマネギのようなレイヤーと見なす必要があり、依存関係は常に外側ではなく内側に移動する必要があります。

したがって、GUI /アプリ層はビジネスロジック層に依存する必要があり、ビジネスロジック層はデータアクセス層に依存する必要があります。

クライアント（web、win、wpf、cli）を分類するか、クライアントプロファイル（クライアントアプリケーションが構成できる）で一般化しない限り、呼び出し元のアプリケーションの名前を渡すことはありません。これにより、ビジネスロジックレイヤーが認識されるようになります。の外層に依存します。

アプリケーションの種類によって、どのような違いがありますか？ここで違いについて少し詳しく説明すると、おそらく誰かがこれを解決する他の方法について役立つアドバイスを思い付くことができます。

しかし、私はあなたの説明された道を進む前に、間違いなく他の方法を探すでしょう。

于 2008-12-03T12:59:02.210 に答える
1

アプリケーションごとに 1 つずつ、2 つの異なるサービスを作成できませんか? 2 つのサービスは、多くのコードを共有するか、呼び出された外部サービスに応じて異なるパラメーター化で単一の内部サービスを呼び出します。

于 2008-12-03T13:56:57.227 に答える
0

設計の観点からは、これは異なるプロファイルを持つユーザーを持つことと同じです。セキュリティの観点から、あるアプリケーションのユーザーが他のアプリケーションロジックをハックとして呼び出す方法を見つけないように、アプリケーションが自分自身を識別するために何かをしていることを願っています。（マフィアと銀行が同時に使用しているHRアプリケーションをイメージしてください。一方の顧客は、共有アプリケーションホストでもう一方の顧客のアプリケーションをハッキングすることに興味があります）

.netでは、クレデンシャルがスレッド上に存在するため、デザインはこのように感じられません（つまり、IIPrincipalを設定すると、その情報はスレッド上に存在します。各メソッド呼び出しとともに伝達されますが、パラメーターとしては伝達されません）。

よりエレガントなデザインの観点から探しているのは、ApplicationIdentity属性かもしれません。あなたはカスタムのものを書かなければならないでしょう、私は今フレームワークでそれを知りません。

于 2008-12-03T13:29:47.313 に答える
0

これは、確かな例がなければ議論するのが難しいトピックです。

あなたはそのように感じるのは正しいです。動作を変更するためにクライアント タイプを送信するのは正しくありません。ログを記録するのは悪い考えではありませんが、それだけです。

これが私がすることです：

  • それぞれの方法を見直して、異なる点とその理由を確認してください。
  • 用途ごとに異なるメソッドを作成します。メソッド名は一目瞭然です。互換性を破る必要がある場合は、より詳細に制御できます (社内専用サービスではやり過ぎになるバージョン管理システムを使用していないと仮定します)。
  • 場合によっては、リクエスト パラメータ (フラグ/列挙値) の方が適切です。
  • 場合によっては、動作環境を知っている方が適切な場合があります (特にデータ セキュリティの場合)。ほとんどの場合、ログイン要求中に送信される動作環境。"attended"/"secure" (エージェント クライアント) と "unattended"/"not secure" (Web クライアント) のようなものです。ここで、セッション キー (HTTP Cookie またはアプリケーション レベルのセッション ID) を交換する必要があります。100% ステートレスにする必要がある場合、特にセッション レプリケーションなしでスケールアウトする必要がある場合、セッションは明らかに機能しません。その要件がある場合は、すべてのリクエストで構造を送信してください。

リクエストは、コード内の関数のようなものと考えてください。関数の動作を変更する魔法のパラメーターを配置することはありません。それぞれが異なる動作をする複数の関数を作成します。関数を使用している人は誰でも、どちらを呼び出すかを決定します。

では、なぜクライアント タイプが間違っているのでしょうか。クライアントの種類自体には特定の意味はありません。それには多くの意味があり、時間の経過とともに変化する可能性があります。これは単なる情報であるため、ログに記録すると便利です。動作環境には特定の意味があります。

考慮すべきシナリオは次のとおりです。元の要求との互換性を損なうような方法でわずかに異なる新しいクライアント タイプが開発された場合はどうなるでしょうか。これで 2 つのリクエストができました。2 つのクライアントが要求 A を使用し、1 つのクライアントが要求 B を使用します。各要求にクライアントの種類を渡すと、サーバーは可能なすべてのクライアントの種類に対して機能することが期待されます。テストと保守がはるかに困難!!

于 2012-06-07T03:33:20.440 に答える