5

WebサービスAPIを設計しようとしています。APIのほとんどの機能は、基本的にWebアプリケーションと非常によく似ています。

ここで問題となるのは、1つのメソッドを作成し、それらをWebアプリケーションとWebサービスAPIの両方に再利用する必要があるかどうかです。（これは論理的な解決策のようですが、非常に複雑です。Webアプリケーションで使用されるメソッドを複製し、両方を別々に保持する方がはるかに簡単です。つまり、Webアプリケーション用の1つのメソッドとWebサービス用の1つのメソッドです。）

どうやってやるの？

1）再利用：1つの主要な方法であり、WebアプリケーションとWebサービスアプリケーションの両方に再利用します（私はこれが好きですが、複雑です）

  • WebAppMethodX --uses-> COMMONFUNCTIONMETHOD_X
  • APIMethodX---使用---->COMMONFUNCTIONMETHOD_X

つまり、Commonfunctionmethod_xには、再利用可能な共通機能のセットが含まれています

PRO：コード、メンテナンス、バグが少なくなります。

CON：非常に複雑

2）DUPLICATE：2つのメソッド。1つはWebアプリケーション用、もう1つはWebサービス用です。

  • WebAppMethodX
  • APIMethodX

PRO：シンプル

CON：複製=より多くのコード、より多くのメンテナンス、より多くのバグ！

4

4 に答える 4

3

パブリックWebサービスAPIと内部アプリケーションAPIでは、ユースケースが異なる可能性があります。共通のサービスプロジェクト/層を作成し、Webアプリと公開されているWebサービスAPIの両方から同じ層を使用します。WebアプリとWebサービスごとに個別のhttp-invokableメソッドを作成します。

それは存在することに帰着します

1）さまざまなセキュリティ上の懸念。たとえば、パブリックAPIを利用してサンプルクライアントアプリケーションを提供すると、他の人があなたが提供したものに簡単に慣れることができるので便利です（多くの場合必要です）。そのクライアントAPIは、内部の安全なロジック/コンテンツが削除された、提供するオブジェクト構造を渡す必要がある場合があります。（コンパイルされたC＃は、Reflectorを使用したクリアテキストである可能性があることを忘れないでください！）

2）さまざまなニーズと制約。たとえば、内部アプリケーション呼び出しの場合、公開されているWebサービスAPIとは異なるビジネスルールを適用することがあります（多くの場合、後者はスコープにはるかに制限されています）。

ビジネスロジックをサービスレイヤーに設計し、それらのクラス/メソッドをそれぞれWebプロジェクトとWebサービスプロジェクトから適切に呼び出すと、ユースケースを混合して複雑にしすぎずに、とにかく多くのコードを再利用できます。

于 2010-12-30T01:41:50.243 に答える
1

Webサービスの1つのメソッドであり、Webアプリケーションにそれを呼び出させます。

両方の「1つの主な方法」が何を意味するのかわかりません。Webアプリケーションにはメインメソッドがありません。それらはアプリサーバーにデプロイされます。

注意すべきもう1つのポイント：POCOインターフェースの観点からサービスを作成する必要があります。これを行うと、展開が選択になります。

于 2010-12-30T01:40:16.900 に答える
1

1つの方法。そうでなければ、バグを見つけて一方を修正し、もう一方を修正するのを忘れると...あなたは泣きます。

于 2010-12-30T01:41:19.413 に答える
0

場合によります..

通常、私はそれらを分離します。このようにして、2つの高レベルプロセス間の相互依存性を取り除きます。コードの再利用はプロセス内で有効ですが、同じサービスで別のアプリを使用できるようにしたい場合があります。

ただし、2つが相互に大きく依存している場合は、同じ関数を再利用して、ある場所で変更すると別の場所で変更されるようにする必要があります。したがって、開発プロセスに関するより潜在的な問題を回避できます。

于 2010-12-30T01:43:10.297 に答える