5

私は現在仕事で取り組んでいるプロジェクトで、週末全体が落ち着かない状況に陥っています。まず、私のシナリオと、私が検討した可能な解決策を説明する必要があります。

大量の外部 API を集約する複合 WCF サービスを作成しています。これらの API は任意であり、この説明に必要なのはその存在だけです。

これらのサービスは、開発期間を通じて追加および削除できます。私の WCF サービスは、いくつかの方法 (REST、SOAP など) を使用してサービスを利用できるはずです。この例では、コードでリクエストを手動で作成することにより、外部 API との通信に焦点を当てています。

たとえば、ServiceXとServiceYの 2 つの API があるとします。

ServiceX は、具体的にはリクエスト ボディ内のデータを含む Web リクエストをPOSTすることによって消費されます。

ServiceY は、URL にデータが追加された Web リクエストをPOSTすることによって消費されます (はい...これが GET であることはわかっていますが、外部 API を作成していないので、それについて説明しないでください。)

冗長で重複したコードを避けるために、コマンド パターンを使用して Web リクエストをラップし、ファクトリを使用してリクエストを作成しています。

ServiceX の場合、データを反復して Post 文字列に配置する必要がある ServiceY とは対照的に、データをエンコードしてリクエスト本文に入れる必要があります。

次のようなクラス構造があります。

public abstract class PostCommandFactory
{
      public ICommand CreateCommand();
}

public class UrlPostCommandFactory:PostCommandFactory
{
      public ICommand CreateCommand()
      {
              //Initialize Command Object Here
      }
}

public class BodyPostCommandFactory:PostCommandFactory
{
      public ICommand CreateCommand()
      {
              //Initialize Command Object Here
      }
}


public interface ICommand
{
      string Invoke();
}

public class UrlPostCommand:ICommand
{
      public string Invoke()
      {
         //Make URL Post Request
      }
}

public class BodyPostCommand:ICommand
{
      public string Invoke()
      {
         //Make Request Body Post Request
      }
}

これにより、データを送信する必要があるときにデータをリクエストにバインドする方法を明確に分離できます。基本的には、GET リクエストを処理するクラスを追加することもできます。これがこれらのパターンの適切な使用法であるかどうかはわかりません。別の方法として、Strategy パターンを使用し、使用する必要がある可能性のあるさまざまな Request メソッドの戦略オブジェクトを指定することを考えています。次のような:

public class RequestBodyPostStrategy:IPostStrategy
{
      public string Invoke()
      {
          //Make Request Body POST here
      }
}

public class UrlPostStrategy:IPostStrategy
{
      public string Invoke()
      {
          //Make URL POST here
      }
}

public interface IPostStrategy
{
      string Invoke();
}

public class PostContext
{
      pubic List<IPostStrategy> _strategies;
      public IPostStrategy _strategy;
      public PostContext()
      {
           _strategies = new List<IPostStrategy>();
      }

      public void AddStrategy(IPostStrategy strategy)
      {
            _strategies.Add(strategy);
      }


      public void SetStrategy(IPostStrategy strategy)
      {
           _strategy = strategy;
      }

      public void Execute()
      {
           _strategy.Invoke();
      }
}

戦略パターンがよりクリーンなソリューションである可能性があると考え始めています。

何かご意見は？

4

2 に答える 2

3

私は両方を使用します。

コマンドは、リクエストをカプセル化し、実装の詳細を隠すためのベスト プラクティスです。よりクリーンなコードを促進するため、1 種類のリクエストしかない場合でも、おそらくこれを使用する必要があります。本質的には、「リクエストがどのように実行および処理されるかについて、コードの残りの部分が知る必要がある絶対最小値は何か」を検討することをお勧めします。これにより、コマンド パターンにたどり着きます。

戦略は基本的に、実行時にシステムを構成して、操作のいくつかの側面を処理するための一般的で一貫した方法を使用します。この場合はリクエストを生成します。これは、戦略/リクエストファクトリのテスト実装を実際の接続などを偽造するために置き換えることができるため、テストの良い方法でもあります.

于 2012-07-09T06:23:28.420 に答える
1

あなたが与えたコマンドと戦略の例に基づいて、コマンドパターンの例は、戦略につながると思われる戦略とまったく同じように見えます. 私も戦略に行きますが、コマンドパターンには、例に含まれているものよりも多くのものがあることを追加したいと思います. 次のような質問を自問する必要があります。

  • これらのコマンドは保存する必要があり、後で実行する必要がありますか?
  • コマンドの内部を気にせずにこれらのコマンドを呼び出す必要がある Invoker はありますか?
  • 異なるコマンドをグループ化して実行する機能が必要ですか?

この場合は、コマンド パターンを選択する必要があります。

于 2012-07-09T05:29:29.760 に答える