17

Symfony 2 で ReST クライアントのベスト プラクティス パターンを確立しようとしています。これは、HTTP/ReST を介して Java ベースのバックエンドと通信するフロントエンド エッジに Symfony アプリがある私の会社では非常に一般的な仕事だからです。

私の考えでは、これらのサービスは、問題の特定のドメインのDDDで「リポジトリ」の役割を果たします。Doctrine で指定された規則に基づいて、これらは Entity オブジェクトを返す Repository クラスに入れられます。

ここでも同じ規則が機能すると思います。ReST クライアントは、Guzzle のようなライブラリを使用してリポジトリ クラスを実装するか、単純な Curl を使用するかは問題ではありません。その後、そこにあるコードは、XML または JSON からエンティティへの往復の基本的な変換を行います。上流の開発者が操作するオブジェクト。これは、他の Symfony 2 ユースケースのパターンと一致しており、DDD の観点から理にかなっています。

誰かがこれに問題があるか、それを行うためのより良い方法を見ていますか?

4

4 に答える 4

2

以下は、symfony2 での REST API 開発を扱うのに最適な記事です:
http://welcometothebundle.com/symfony2-rest-api-the-best-2013-way/

FOSRestBundleとNelmioApiDocBundleは、迅速な REST API 開発に適しています。公式ドキュメントにアクセスして、インストール、構成、および使用方法を知ることができます。

于 2016-05-26T10:35:34.887 に答える
1

Symfony のリポジトリをそのように使用する場合、リポジトリを誤用していると思います。リポジトリ内にセッターとゲッターを用意し、サービスで guzzle/curl を使用した処理を行う方がよいでしょう。

コントローラ / コマンド -> サービス メソッド -> リポジトリ

次に、必要に応じてコマンド/コントローラーを作成し、必要に応じてサービス内のメソッドを公開できます。

于 2016-04-13T11:34:59.117 に答える
1

これは、関連するすべてのキャッシュ層も正しく考慮して、取得する REST オブジェクトの TTL を超えてリポジトリがキャッシュされないようにする場合に機能します (etags または expire ヘッダーまたは REST サーバーが使用するものによって設定されます)。

確かにリポジトリは正しいレイヤーですが、Symfony では 1 つ上のレベルに移動してエンティティ マネージャーと見なしたいかもしれません。これにより、そのレベルでの操作 (永続化、削除、フラッシュなど) を抽象化できるからです。

于 2015-06-23T10:08:14.630 に答える
1

あなたが概説したアプローチが好きです。リポジトリは、ドメイン モデルから ReST クライアント コードを分離する腐敗防止レイヤーと考えることができます。

于 2012-12-07T20:14:01.987 に答える