web-dev-qa-db-ja.com

リポジトリ、サービス、アクション/コントローラーとは何ですか？

私はSlim3とPHPを使用してプロジェクトを開始しました。アプリケーションアーキテクチャの限られた知識を使用しています。計画はプロジェクトを作成し、アプリケーションの懸念を切り離すことでした。すべて順調でしたが、アプリケーションとして混乱が生じました。成長した。

これを行うための全体的なアイデアは、開発を容易にすることでした。それはある意味ではありますが、データフローを監視するのは複雑な場合があります。

リポジトリ、サービス、コントローラ/アクションとは何かについてアドバイスが必要です。そして、システムでどのように機能するか。それらについての私の現在の理解は以下の通りです：

リポジトリ

リポジトリは、サービス層とモデル層の間で使用されます。たとえば、UserRepositoryでは、データベースから読み取り/書き込みするコードを含むメソッドを作成します。 PHPでは、repoメソッド内でPDOまたはORMが使用されます。例えば：

class UserRepository
{
    public function findByID($id) { ... }
    public function findByEmail($email) { ... }
    public function findByMobile($mobile) { ... }
    public function createEmail($email, $firstname, $lastname, $password) { ... }
    public function createMobile($mobile, $firstname, $lastname, $password) { ... }
}

そこにいくつかのサンプルメソッドを入れました。しかし、おそらくもっとたくさんあるでしょう。

サービス

サービス層は、アプリケーションロジックをカプセル化します。たとえば、UserServiceは、アカウントの作成と、ユーザーを登録するために必要なロジックの実行を担当します。サービスはサードパーティにすることもできます。たとえば、FacebookのSDKまたはORMのサービスを作成します。

サービスの例：

class UserService
{
    public function createMobile($mobile, $firstname, $lastname, $password)     {
    /*
     * Call a validation service to validate input
     */
    ...

    /*
     * Use UserRepository's findByMobile() to check if account exists
     */
    ...

    /*
     * Use UserRepository's createMobile() to create account
     */
    ...

    /*
     * Call SMS service to send verification code
     */
    ...
    }

    public function createEmail(...) { ... }
    public function getFollowers (...) { ... }
}

アクション

これが本当の用語かどうかはわかりません。これはSlim Frameworkのドキュメントで使用されており、薄いコントローラーを表しているようです。

アクションにはほとんどロジックが含まれておらず、サービスの呼び出しに使用されます。正当な理由がない限り、アクションがリポジトリを直接呼び出すことはめったにありません。アクションは、クライアントから応答を返すために、サービスから返されたデータに対して基本的なチェックを実行します。

それらは個々のルートに関連付けられています。私はそれらを次のように使用しています：

class ActivateEmailAction extends Action {

    public function __invoke(Request $request, Response $response, $args = [])
    {
        if(!$this->ci->ActivationService->activateEmail($args['token'])){
            return $response->withJson([
                'status' => 'error',
                'data' => null,
                'message' => 'Invalid verification token'
            ]);
        };

        return $response->withJson([
            'status' => 'success',
            'data' => null,
            'message' => null
        ]);
    }
}

これらのパターンを正しく使用していますか？私が採用したと思われるフローは次のとおりです。

  1. すべてはルートから始まります。たとえば、リクエストが/create。ルートはアクションに登録されています。
  2. アクションは、呼び出すサービスを決定します
  3. サービスはロジックを実行し、必要に応じて他のサービスやリポジトリを呼び出します
  4. サービスがデータをアクションに引き渡す
  5. アクションが応答を返します

何かアドバイスをいただければ幸いです。

design-patternsobject-oriented-design
7
BugHunterUK

私は実際にあなたがこれを実装している方法が好きです。

いくつかの答え：

リポジトリ、サービス、アクション/コントローラーとは何ですか？

  • リポジトリ：リポジトリは、ドメイン/ビジネスレイヤーとデータマッピングレイヤーの間のゲートウェイです。データマッピングレイヤーは、データベースにアクセスして操作を実行するレイヤーです。基本的に、リポジトリはデータベースへのアクセスを抽象化したものです。

  • Service：サービスはビジネスロジックにAPIを提供する必要があるため、リポジトリへの抽象化です。ここで、@ Ceradに少し同意しません。サービスは、リポジトリへのアクセス。それ以外の場合、ビジネスレイヤーはデータアクセスレイヤーの抽象化であるため、依存関係の逆転の原則（SOLIDではD）に違反します。

  • Actions/Controllers： A/Cオブジェクトは、入力とドメインロジックの間のゲートウェイとして機能し、入力の処理方法と応答の出力方法を決定します。

データフローを把握するのが複雑な場合があります。

はい、時々そうですが、私が読んでよく覚えていないように、醜いコードで後者の困難を抱えているよりも、体系化された原則ベースのコードを持っている方が良いことを意味します。

最終的に：

使用しているアーキテクチャモデルはレイヤードアーキテクチャであり、すべてがレイヤーで分離されており、上位レイヤーは下位レイヤーの抽象化です。そのため、すべてのレイヤーはすぐ下のレイヤーのみを参照する必要があります。

お役に立てれば。

9
J. Pichardo