1

これはコード設計の問題です:)

httpリクエストヘッダーを取得してAPIキーを検証するDelegatingHandlerがあります。私が推測するかなり一般的なタスク。コントローラーでビジネス ロジックを呼び出し、すべてのビジネス関連情報を渡します。ただし、特定の API キーに応じて、ビジネス ロジック (個別のアセンブリ) 内の動作を変更するという課題に直面しています。

さまざまな可能な解決策が頭に浮かびます...

  1. ビジネス ロジック メソッドのシグネチャを変更して、API キーも要求するようにします。

    public void SomeUseCase(Entity1 e1, Entity2 e2, string apiKey);

  2. HttpContext.Current を使用して、現在のリクエスト コンテキストにアクセスします。ただし、HttpContext を使用すると、ホスティング オプションが IIS に制限されることをどこかで読みました。それに適したオプションはありますか？

    var request = HttpContext.Current.Request; // 次にヘッダー情報を抽出します

  3. セッションを使用します（実際にはその道を行きたくない...）

その話題についてどう思いますか。

私は＃1に行きますが、ビジネスロジックメソッドに環境的なものを混ぜるという考えは好きではありません. しかし、見方によっては、API キーは実際にはロジックに関連していると主張するかもしれません。

更新 #1: delegatingHandler を使用して apiKey を検証しています。検証が完了したら、それを Request の Properties コレクションに追加します。

問題の部分は、「api-key」または RegisteredIdentifier がビジネス ロジック層にどのように渡されるかです。現在、オブジェクト (IRegisteredIdentifier など) をパラメーターとしてビジネス ロジック クラスのコンストラクターに渡しています。これを解決するためのこれ以上エレガントな方法はないことを理解しています(?)。メソッドのシグネチャを変更することを考えましたが、インターフェイスの汚染かどうかはわかりません。一部のメソッドは api-key を使用する必要がありますが、ほとんどのメソッドはそうではありません。経験上、その数は減少するよりも増加する可能性が高いことがわかります:) したがって、私の bl クラスでそれへの参照を保持することは良い選択のようです.

回答ありがとうございます - それらはすべて私の解決策の一部だと思います。私はStackOverflowを初めて使用します..しかし、私が見る限り、回答をまだ評価できません。安心してください 私はまだ感謝しています:)

4

3 に答える 3

1

2 つの異なるオプションを提案します。

  • 値をカスタム HTTP ヘッダーに昇格させます (例: mycompany-api-key: XXXX など)。これにより、委任ハンドラーが標準の HTTP 仲介のように機能します。これは、リクエストをセカンダリ内部サーバーに渡す場合に便利です。

  • api-key を request.Properties ディクショナリに入れます。Properties ディクショナリの目的は、リクエストに関するカスタム メタ情報を配置する場所を提供することです。

HTTP は、認証/承認が実際の要求と直交する関係であることを確認するために懸命に働いています。

于 2013-02-13T15:05:56.967 に答える
0

私はオプション 1 を選びます。ただし、ビジネス ロジックにエンティティ RegisteredIdentifier (Jim Arlow と Ila Neustadt による Enterprise Patterns と MDA) を導入することもできます。api-key は RegisteredIdentifier に変換できます。

RegisteredIdentifier id = new RegisteredIdentitief(api-key);

public void SomeUseCase(Entity1 e1, Entity2 e2, RegisteredIdentifier id);
于 2013-02-13T08:26:29.410 に答える
0

ビジネス ロジック レイヤーは、API キーに依存しています。だから私は提案します：

interface IApiKeyProvider
{
    string ApiGet { get; }
}

..次に、そのインターフェイスを実装するオブジェクトが (コンストラクター、セットアップ、またはそれを必要とする各メソッドで) 提供されることを BLL に要求させます。

将来的には、1 つの API キーではない可能性があるためです。重要な点は、BLL が何かに依存していること、および何かのコントラクトを定義していることを識別することです。

実際の例:

次に、DI コンテナー (Ninject など) で、独自の ConfigFileApiKeyProvider (またはその他) の実装を、API キーを持つ "場所" (レイヤー) でそのインターフェイスにバインドします。したがって、BLL を呼び出すアプリは、API キーの指定方法を指定/構成します。

編集：これが「HTTP経由で行う方法」の質問であり、コードアーキテクチャ/コード設計の質問ではないという部分を誤解しました。そう：

  • HTTP ヘッダーは、トランスポートに関して進むべき道です
于 2013-02-13T15:17:19.603 に答える