リポジトリパターンを使用しない方法

この記事は、 Laravel5でのプロジェクトの長期にわたる開発中に私が犯した非常に不快なアーキテクチャ上の間違いの結果として得られた一種の経験です。



プロジェクトでリポジトリパターンをどのように使用したか、特定された利点と欠点、開発全体にどのように影響し、どのような利益が得られたかについて説明します。

はじめに

この記事は、デザインパターンに精通し、スマートブックを読み、いわば「プロダクション」にすべてを適用しようとしている開発者に焦点を当てている可能性が高いことをすぐに警告します。 ActiveRecordを使用するフレームワーク（Yii、Laravelなど）を使用した開発について説明します。これは、ActiveRecordのおかげでレーキを踏んでさまざまな問題を解決する方法を学び続けているからです。

リポジトリパターン

文字通り、私はリポジトリとは何かを検討することを提案します 。

リポジトリは、特定のタイプのエンティティのコレクションストレージの概念です。

このパターンについて詳しく読むことができます：

• リポジトリパターン。 基本と説明
• リポジトリ
• また、プログラミングに関する多くの書籍（Martin Fowler et al。）

一般に、多くの情報があり、リポジトリが何であるかを理解することは非常に「簡単」です。

リポジトリから始める

中規模および/または大規模（負荷の面ではなく、大規模なコードベースと長期サポート）プロジェクトを開発した場合、ActiveRecordの使用時に発生する欠陥や問題に直面する可能性が高くなります。 主なものは小さなリストで区別できます：

• 単一の責任の違反。
• 最初の段落から、「モデル」は非常に「太っている」ことがあります。
• 初心者の場合、MVCの誤った概念が形成されます。ここで、Mはモデルとして理解され、これは== 1クラス、主にActiveRecordです。
• 何らかの理由で一度に多数のレコードを処理する必要がある場合、データのインポート/エクスポートの非常にリソース集約型の組織。
• 必要に応じてカスタムSQLクエリを記述するのは不便であり、現実的ではない場合があります。

ActiveRecordにも当然利点がありますが、これは記事の範囲を超えているため、それらについては言及しません。 同時に、ひと言で言えば、「ActiveRecordは高速、シンプル、簡単」です。



そのため、ActiveRecordに基づいたフレームワークを使用して数年間、私はほとんどすべての欠点に遭遇しました。 そして、新しいプロジェクトのアーキテクチャを設計するときに、どういうわけかスマートな本や記事を読んで、Repositoryパターンを実装することにしました。



シンプルな実装と説明に基づいて、すべてがシンプルです。インターフェイスを取得し、それらを「ストレージ」からデータを取得するリポジトリとなるクラスにバインドします。 すべてが正常であり、いつでも別のリポジトリをバインドし、選択メソッドの実装を置き換えることができます。一般に、すべてが明確です。



ステータスをSystems Architectに変更しました

あなたの「リポジトリ」は本当にリポジトリですか？

そして、実装を本当に置き換える必要がある瞬間がありました。 私は笑顔で考えてオフィスに到着しました。「どうすればすべてを簡単に変更できますか。別のクラスを作成し、バインド時に行を変更するだけです」。



ただし、最初のケースではファイルから、別のケースではサードパーティAPIからの選択を置き換えることがタスクでした。 掘り下げてすべてを整理し始めたとき、「リポジトリ」がモデルを返していることに気付きました。 はい、そうです、私のRepositoryパターンは、プロジェクト全体を歩き続けているすべての同じモデルを返します。



はい、インターフェイスのおかげで、実装を簡単に置き換えることができましたが、返されるデータの形式は変更されました。 以前はActiveRecordクラスのインスタンスでしたが、今では私のリポジトリが配列またはコレクションを返すことができます。



これはどういう意味ですか？ これは、私のチームの代表者が「モデル」の個々の特性を使用できることを意味します。 たとえば、ミューテーターやアクセサー、またはロジックを使用してモデルにメソッドを記述し、どこでも呼び出すことができます。 そのため、実装を置き換えて、データ形式を変更しましたが、現在はアプリケーション全体が正常に機能することを保証できません。 モデルの無害なメソッドをどこからでも呼び出すことから始まり、フォームでsave（）を呼び出すことで終わります。 誰も知らない、誰も覚えていない、特にプロジェクトが去った数人の開発者を生き残り、新しいものがそれらを置き換えた場合。

パニックなし、テスト

その後、テストを実行できることを思い出しました。 私はパートナーに目を向け、「テストを書きましたか？」と尋ねました。 次に、彼は別の同僚に目を向け、同じ問題を明らかにしました。 一般的に、判明したように、アプリケーションの大部分はテストでカバーされていませんでした。

何がありますか？

そのため、抽象化の追加レイヤーをリリースしました。これは、モデルがプロジェクトを歩き回って歩き続けるため、より大きな入力しきい値と、0に近い効率の開発のためのより多くの時間を必要とします。



ステータスをジュニアアシスタントに変更しました

問題をより詳細に理解します

システムをより深く理解し、例を見てみると、非常に多くの開発者がそのような間違いを犯し、さらに悪いことに気づきました。



それは良くないかもしれませんが、リポジトリパターンの実装が貧弱である同様の例を提供したいと思います 。



トピックに関する情報を見ると、このアプリケーションがLaravelで見つかりました。



https://github.com/Bottelet/Flarepoint-crm/



UserRepositoryの例を見てみましょう。



https://github.com/Bottelet/Flarepoint-crm/blob/develop/app/Repositories/User/UserRepository.php



ここで解析したい方法の1つ（このすべてが消える場合）：

... public function create($requestData) { $settings = Settings::first(); $password = bcrypt($requestData->password); $role = $requestData->roles; $department = $requestData->departments; $companyname = $settings->company; if ($requestData->hasFile('image_path')) { if (!is_dir(public_path(). '/images/'. $companyname)) { mkdir(public_path(). '/images/'. $companyname, 0777, true); } $settings = Settings::findOrFail(1); $file = $requestData->file('image_path'); $destinationPath = public_path(). '/images/'. $companyname; $filename = str_random(8) . '_' . $file->getClientOriginalName() ; $file->move($destinationPath, $filename); $input = array_replace($requestData->all(), ['image_path'=>"$filename", 'password'=>"$password"]); } else { $input = array_replace($requestData->all(), ['password'=>"$password"]); } $user = User::create($input); $user->roles()->attach($role); $user->department()->attach($department); $user->save(); Session::flash('flash_message', 'User successfully added!'); //Snippet in Master.blade.php return $user; } ...
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

• まず、Repositoryはストレージを使用した抽象的な作業です。 つまり、何かを取るか、何かを置くことです。 リポジトリにロジックはありません。
  
  
  
  
• 第二に、リポジトリ内でbcryptなどを使用することはできません。アプリケーションを自分で作成する場合、コマンドを持っている場合はこれを覚えているため、誰かがリポジトリに暗号化されたパスワードを入力すると、エラーを探す可能性があります長い間。
  
  
  
  
• さらに、Repositoryは抽象リポジトリであるため、コンソールコールを使用して何かを保存する必要があるため、Sessionを知ることができません。
  
  
  
  
• 繰り返しますが、結果は、制御不能にアプリケーションを「ウォークスルー」するモデルです。 ActiveRecordのすべての魔法を使用することからあなたを守る人はいません。

ほとんどの場合、このような例をより詳細に分析すると、さらに多くの興味深いことが見つかります。

これは、人々がパターン自体に到達するのではなく、スマートブックを読んでリポジトリをポップするなどの典型的な例です...

リポジトリを正しく使用する方法は？

• まず、最初に、この設計パターンが必要な理由を明確に理解する必要があります。
  
  
  
  
• 第二に、リポジトリは、アプリケーションによって駆動されるエンティティの存在を前提としています。 つまり、リポジトリは、データを格納するための単一の形式を受け入れて返す必要があります。 通常、これはロジックのないゲッターとセッターを持つEntityクラスです。 データソースを変更した場合、戻り形式を変更しないでください。
  
  
  
  
• さらに、ActiveRecordでフレームワークを使用すると、おそらく99％のリポジトリは冗長になります。ActiveRecord自体の位置は、Repository / Entity / Presenterの特定の組み合わせであり、Yii2の場合は、フィルターと検証もあります。 したがって、リポジトリ内のActiveRecord全体を本当に正確かつ効率的にラップするには、印象的な抽象化層とインフラストラクチャ全体を構築する必要があります。
  
  
  
  
• それでも何らかの理由でYii、Laravel（または同様の何か）とリポジトリを友達にする必要がある場合、 Doctrineがおそらく最良の選択肢です。 Yii2とLaravel5には間違いなく拡張機能があります。つまり、誰かが同じことをしているということです。

リポジトリパターンまたはそれに類するものの実装

Laravel5のリポジトリパターンの実装について説明している記事を見つけました （Yii2の場合もほとんど同じです）。 しかし、私の個人的な意見では、ActiveRecordを使用してクエリを記述する構造化されたアプローチについて説明しています。 一方で、便利で、コードの重複が減り、モデルの重量が減り、アーキテクチャがよりエレガントになります。 一方、リポジトリは、「抽象リポジトリ」としての役割を完全には果たしていません。モデルを使った作業と、すべての魔法を備えたActiveRecordへの完全なバインディングが進行中です。



モデルで作業している場合、データソースを変更するとき（データベースまたはフレームワークを変更する必要はありませんが、サードパーティAPIなどの別のリソースから、またはクエリビルダーを使用して複雑なカスタムリクエストを作成することで、データを取得するだけで十分です） 、および新しい実装は配列またはコレクションを返すため、アプリケーションの安定した動作を保証できない可能性があります。 そのため、モデルのどのメソッド、アクセッサ/ミューテータ、およびその他の魅力がどこで使用されたのか（プロジェクトが大きく、自分だけで作成されていない場合）

結論

アプリケーションの設計において有用であると同時に苦い経験を​​したことから、私自身が共有したい次の結論を強調することができます（これは誰かに役立つかもしれません）。

• リポジトリを使用している理由と、実際に設計パターンを明確に理解する必要があります。 実装方法を知っている、または理解しているだけでは十分ではありません。それを使用する理由と本当に必要なのかを理解することの方がはるかに重要です。
• 新しい商業プロジェクトで新しく習得した知識を練習しないでください。 猫または「ホーム」プロジェクトで練習します。
• ActiveRecordを使用したフレームワークでリポジトリを操作しないでください。 繰り返しますが、ほとんど何をしているのかを本当に知っていて、その結果を完全に認識している場合を除き、ほとんどの場合、冗長になります。
• 他のツールを表示して視野を広げてください。 1つのフレームワーク開発者にならないでください
• テストはいいだろう。