0

Stock Tase 情報を説明するさまざまなサービスに接続しています。今のところ3つのサービスがあります。各サービスは、XML、Json、パイプで区切られた文字列など、さまざまな方法で情報を返します。サービスの数は、近い将来に増加する可能性があります。

これを、最大限の抽象化で最も柔軟な方法で実装したいと思います。唯一のパターン (私がよく知っているものから) は、ファクトリ パターンまたは抽象ファクトリです。たぶん、ここでは戦略パターンもオプションです。

より良い実装方法を提案できますか？

概要：

StockInformationParser 
-> Connects to Service 1 || Service 2 || or Service N 
-> Parses and analyses information
-> returns StockInformationInfo.
4

3 に答える 3

2

私は少し異なるアプローチをします。データベースを作成してこれらのサービスを入力すると、お気に入りの SQL でデータベースを簡単にクエリし、Group By、Order、および Join を使用できます。

利点は、

  • クエリが必要なため、クエリ アダプターを再発明する必要はありません。
  • フェッチされたデータがデータベースの行として保持されると、異なる形式について心配する必要はありません。
  • キャッシングの改善 サービス障害や接続の問題が発生した場合でも、過去のデータを見ることができます。
于 2013-04-24T08:21:43.670 に答える
2

これらの外部サービスはすべて、最終的に 1 つの同じドメイン モデルにマップされると想定しています。

その場合、次のことができます。

  • これらのクライアント用に最適化されたデータ コントラクトを使用して、クライアントが使用できる操作を含む内部サービスを作成します。
  • 内部サービスは、基盤となるリポジトリとドメイン モデルを使用します。
  • リポジトリは、データが取得される方法を抽象化する責任があります。内部的には、外部プロバイダーからデータを取得し、これらをドメイン オブジェクトにマップします。外部サービスごとにプロバイダーを作成し、それらをリポジトリーで使用できます。外部サービスが追加された場合は、新しいプロバイダーを追加してリポジトリ ロジックに追加するだけです。

個人的には IoC が好きなので、すべてのコンポーネントのインターフェイスを作成し、具象インスタンスを注入します。これにより、さらに柔軟でテストしやすくなります。

于 2013-04-24T08:28:20.973 に答える
2

あなたの状況に関しては、より多くの設計パターンを適用し、以下のように問題を解決するために組み合わせる必要があることをお勧めします。

  1. 各結果が各サービスを返すたびに、同じメソッドを使用する解析エンジンが必要になる場合がありますが、Json、Xml、rss などの形式は同じですが、メソッドは同じですが形式が異なるため、戦略パターンを適用して解決する必要があります。

  2. 各サービスには接続するためのスキーマ ファクトリが必要なので、抽象ファクトリまたはファクトリ デザイン パターンが適切です。

  3. 最後に、結果を簡単に変更できるように抽象化するか、後でここでプロキシ パターンを適用できるようにする必要があります。

この助けを願っています。

于 2013-04-24T08:09:36.653 に答える