2016-05-06 18 views
0

だが、私はここに1対多の関係を持っているとしましょうベストプラクティス:
顧客あり、多くのクレジットカードREST APIの1対多のリソース関係

やクレジットカードのためのAPIエンドポイント:
GET /顧客/ {CUSTOMER_ID} /カード/ {card_id}
GET /顧客/ {CUSTOMER_ID} /カード
POST /顧客/ {CUSTOMER_ID} /カード
PATCH /顧客/ {CUSTOMER_ID} /カード/ {card_id}
DELETE /顧客/ {CUSTOMER_ID} /カード/ {card_id}カードに関連する操作のため

5の方法:
1のカードを取得します顧客
2.顧客のために
4.アップデート
5.顧客

マイAPIアーキテクチャレイヤリングのカードを削除」カードの顧客の詳細情報をカードを作成し、顧客
3のすべてのカードを取得コントローラ - >サービス - >リポジトリを使用します。
あります。
CustomersController、CustomersService、CustomersRepository、CardsService、CardsRepositoryです。私はカード関連業務のための各メソッドを置くべきで、どのようにコントローラ&サービス&リポジトリ層との関係は次のようにあるべき場所

私の質問は、ありますか?

現在、私はこのように考えています:
CustomersControllerにはCustomersServiceとCardsServiceがあります。 CardsServiceにはCustomersRepositoryとCardsRepositoryがあります(通常どおりコンストラクター経由で注入されます)。上記5つの方法はすべてCardsServiceにあります。 CardsServiceのCustomersRepositoryの目的は、私のDBからストライプの顧客IDを取得して、同じ操作をストライプでも実行できるようにすることです。

このアプローチは、ベストプラクティスに従って正しいですか?それとも、代わりにCustomersServiceに5つのメソッドを置いて、CardsServiceをまったく使用しないのですか?

これには最適な解決策はありますか?

追加情報:
- 私は決済プラットフォームに公開レストのAPIを1として

答えて

0

としてPHPとLaravelフレームワーク、およびストライプを使用しています、私はカードが顧客なしでは存在できないと推測。したがって、残りのリソースはCustomersResourceとし、上記の残りのAPIはすべてこのクラス内に存在する必要があります。

このクラスは、たCustomerServiceと注入さCardServiceインスタンスの両方を持つことになります。

次の変更は、単一責任の原則であるを破棄するため、CardServiceに対するCustomerRepositoryの依存関係を削除することです。

簡単に言えば、カスタマーサービスは顧客関連の操作を処理し、カードサービスはカード関連の操作を処理する必要があります。これらの両方を混ぜてはいけません。

お客様のカード情報を使用して顧客オブジェクトを構築する必要がある場合は、残りのリソースからカスタマーサービスとカードサービスへの呼び出しを調整し、同じものをユーザーに送り返します。

希望します。