ただのREST-APIであるサービスがあるとしましょう。このRESTAPIはいくつかのデータを提供します。
私が理解している限り、これは理にかなっていますが、このサービスとの間で送受信されるデータをDTOにカプセル化できます。いくつかのビジネスオブジェクトがあるので、これは完全に理にかなっていますが、多くの場合、ある方法でそれらをシリアル化する必要があります。私が理解している限り、これは一般的に受け入れられており、この部分に関してそれを抽象化する方法を知っています。
次に、このDTOはREST-APIを介して送信されます。サーバー側に関しては、データを提供または受信するコントローラーがいくつかあるため、非常に単純に継ぎ目がありますが、（少なくとも今のところ）問題は発生していません。
だから私の質問に関して。クライアント側には、このAPIにアクセスするオブジェクトがあります。このオブジェクトには、私の実装にはhttpクライアントが含まれ（おそらく、このオブジェクトからそれらを切り離すかどうかはわかりません）、APIにアクセスするためのメソッドも含まれています。したがって、何らかの方法で、httpクライアントの使用を抽象化し、APIにアクセスします。
APIにアクセスするこのオブジェクトにどのように名前を付けますか？
私は今それらにXXXManager / XXXHandler / ...という名前を付けていますが、この名前は一般的なものとはほど遠いものであり、これには何らかの規則やパターンが必要だと思いますか？それらにXXXServiceという名前を付けることも、完全に正しくないと感じます。私にとってのサービスはサーバー側の部分のようなものであり、このオブジェクトはサービスにアクセスしているからです。
では、この種のオブジェクトにどのように名前を付けますか？この種のサービス/ APIアクセサーを処理するためのより深いパターンはありますか？
ここで機能するモデル/パターンは、次のlayered architectureように機能するクラシックです。
HttpClientはApiClient、REST APIにアクセスするためのメソッドを公開するクラス（名前を付けましょう）をラップする必要があります。これらの各メソッドでは、httpClientを使用してHTTP呼び出しを実行します。
を使用し、ApiClient独自のビジネスロジックを適用するService / Managerクラスのレイヤーがあります。
UIコンポーネントのレイヤーがあり、サービス/マネージャーを挿入してデータを取得し、UIにレンダリングします。
このようにして、レイヤーを分離し、コードのスケーラビリティとテスト容易性の両方を向上させます。
命名は、クライアント側の実装/フレームワークのタイプによって異なります。
Webフロントエンドクライアントがある場合、その名前TransactionServiceは、このクラスが外部トランザクションサービスServiceと通信することを示しています（サーバー側のコンポーネントに関連付けられた名前ではありません）。
この記事はインターネットから収集されたものであり、転載の際にはソースを示してください。
侵害の場合は、連絡してください[email protected]
コメントを追加