3

背景
C# を使用して、SOAP Web サービスとやり取りしています。私は Visual Studio で作業しており、サービス リファレンスを正常に設定しており、コードで Web サービスを使用できます。

私の質問は、言語としての C# の強力な機能を考慮して、クライアント/ラッパーを API に合わせて設計するための "最善の方法" に関するものです。

中央の「リクエスト」クラス
サービスへのリクエストを処理するための全体的なクラスを作成し、API 固有のエラー (多数あります) のさまざまな順列をすべて処理し、適切に機能を低下させることを考えました。このクラスは、API クライアントの「コントローラー」になる可能性もあります。これは、内部呼び出しと外部世界/コードの間の全体的なインターフェイスも提供します。

次に、各 API 呼び出しが必要とし、返すことができるデータ型が非常に多様であることに気付きました。確かにこれは、この「リクエスト」機能を一般的に処理できないことを意味します (そして、認証、車両の位置、ジョブ/注文など、特定のタイプのリクエストごとに実装する必要があります)。

または、可能な場合、言語としての C# は、抽象的な方法で型を操作するのにどのように役立ちますか?

いつものように、お読みいただきありがとうございます。

4

1 に答える 1

2

質問は詳細が少し曖昧ですが、私はいくつかのアドバイスを提供しようとします。

まず、外部 API のラッパーを作成するのが賢明だと思います。外部の電子メール プロバイダーの例を使用して、質問に答えます。

サードパーティの電子メール API があり、その周りにラッパーを作成したいとします。

まず、メール API が動作すると予想される方法で動作するラッパーを作成します。次のようなメソッドが必要です。


public EmailResponse SendEmail(EmailRequest request) { }
public User GetUser(string email) { }
public void OptOut(string email) { }

私はクライアントとして、ドメインの汎用性と使いやすさの両方を備えていると思うものを設計することから始めます。

次に、サードパーティ API に直接マップするラッパー インターフェイスの実装を作成します。上記の例では、電子メールを送信するために 2 つの外部 API 呼び出しが必要かもしれませんが、ラッパーを使用している人はそれを知りません。

私の意見では、特定の実装と密接にバインドしすぎると、ラッパーは価値がありません。

C# には、この種のアプローチを可能にする言語機能がたくさんありますが、単純なインターフェイスを使用するだけでニーズに合うと思います。これ以上難しくする必要はありません。

于 2013-02-10T21:55:05.427 に答える