みなさんこんにちは。 私はあなたの前で告白し、私がLaravelで開発するとき私がどのように感じるかについて少しお話したいです。 いいえ、考えないでください。私はこのフレームワークを崇拝し、それを作成し、サポートしてくれたチームに非常に感謝しています。彼らは非常にクールな仕事をし、私の意見では、LaravelはSymfonyの最高の継続です。
愚かなコードが大好きです。 10年経っても、顧客から変更を求められた場合は、金曜日の企業パーティーの後であっても、古いコードを壊すことなく、ロジック全体を掘り下げることなくこれを行うことができるという意味で愚かです。 そして、それを理解するために認知的な努力をする必要がないという意味で愚かです。 しかし、Laravel Eloquent ORMには、私を泣かせるアーキテクチャソリューションが1つあります。 面白い？ 猫の下に来てください。
OOP、デザインパターン、SOLID、DDD、その他の恐ろしい言葉が最初に私たちを怖がらせてくれます。
これらはLaravelとSymfonyが好きです。 彼らはあなたが箱から出してすぐに最も愚かで安全なコードを書くことを可能にします。 はい それらのそれぞれには欠点があります...しかし、Laravelには私を最も悩ませるものがあります。 これは、モデルの操作にActive Record Pattern（AR）を使用しています。
手始めに、このパターンについて少し。 これは何ですか？ 理解するために、アプリケーション設計のこの作品の親であるリポジトリパターンに移動する必要があります。 このパターンはコレクションです。 エンティティのコレクション（エンティティ）。一般的な抽象ストレージの場所でそれらを取得、変更、保存、削除、管理できます。 100％のケースのうち90％で、この保管場所はさまざまなデータベースです。 しかし、ファイルシステム、何らかのキャッシュ、さらには外部APIが存在する場合があります。
このアプローチは、共有責任の原則とDDDアプローチと完全に一致しています。 さらに、このアプローチのおかげで、弱い接続性が実装されています。アプリケーションがどのように保存されるかは気にしません。データのオブジェクト表現を直接操作する場合はEntityを使用し、リポジトリとやり取りする必要がある場合はRepositoryを使用します。
しかし、LaravelはARの使用方法を決定しました。これは、素早いプロトタイプを作成する必要がある場合、紛れもなくクールで信じられないほど便利ですが、いくつかのデータソースとやり取りし、システム内でそれらを操作する必要があるとき、それは信じられないほどの頭痛になります。
ARは、エンティティとリポジトリを1つのモデルにマッピングするパターンです。 つまり、オブジェクトはデータベース内の特定のレコードの表現になります。 そして...何？ これは何につながり、なぜそれがそんなに迷惑なのですか？
まず、共有責任の同じ原則に違反します。ある場所でリポジトリを操作するロジックと、別の場所でエンティティを操作するロジックです。 私のシステムのフレームワークでは、呼び出しチェーンを介してオブジェクト表現のデータベースから行を転送したくないため、これは重要です。 モデルを渡したいです。 私はそれがどのように判明し、変化し、持続するのか気にしないでください。 データベースの行ではなく、モデルのみとやり取りできるメソッドが必要です。
第二に、（永続層-ストレージ層-がエンティティ層と接続されているという事実の結果として）単純にモデルの保存場所を変更することはできません。 はい、サポートされているデータベース内で、構成内でこれを行うことができます。 または、特定のモデルのみを変更し（これにより、基本クラスのメソッドを取り除くことができないため、クエリビルダーメソッドを削除しません）、コード内で大量のエラーが発生する可能性があります。サポートします（これは常に発生します）。
第三に。 エンティティをテストしたい。 私が加えた変更が私のビジネスロジックを壊さないことを確信するために、私はそれを気にしたいです。 そして、実践が示すように、ARの場合、これを行うことはできません。なぜなら、単一の責任という悪魔的な原則に違反しているからです。 ここで私は少し不誠実です。 モデルのテストは可能です、ただ...少し複雑です。
それにもかかわらず、このパターンの利点について言わないことは不可能です。 全体的にプラスなのは、「すばやく簡単に、ためらうことなく」ということです。 ロジックがアクションに近く、常に一緒に使用される2つのパターンをマージすると、コードの量をわずかに減らす便利なツールが得られました（複雑な方向で、「ダムコード」を覚えていますか？）。 また、MVP形成の段階で不必要な問題を取り除くことができます。これは必須です（実際には、これはめったに起こらないことを示していますが、それでも書き換えが予定されています）。 これにより、思考を「どのように行うか」という質問から「何をするか」という質問に変えることができます。つまり、テクノロジーに関する不要な質問を取り除き、ビジネスロジックに進むことができます。
Laravel Eloquent ORMを長年使用してきた結果、どのような結論に達しましたか？ Active Record肉体の悪？ いいえ、これはいくつかの状況、特に単純なアプリケーションまたはそのようなアプリケーションのプロトタイプを作成する段階では、最もクールなツールです。 しかし、これは、アプリケーションが成長し、多数のデータソースを操作し、100％のテストカバレッジでコードを記述しなければならず、大きな問題が発生した場合に機能することは不可能です。
はい、新しいチップが発明されています（ トラッカー ？）、しかし、トリックを続けましょう。 しかし、それでもフレームワークからもう少し自由になりたいです。特に、多くの人にとって非常に良いからです！