php - エンティティを管理するsymfony

Question

私が苦労して学んだように、エンティティはデータを保存するために使用されるため、実際のロジックを保存するべきではありません。

また、コントローラーには「実際のコード」を含める必要はなく、必要に応じていくつかの値を設定し、実際に作業に使用されるサービスを指すようにする必要があることを読みました。（コントローラーから脂肪をトリミング）。

私は要点を理解しており、私は Symfony の初心者ですが、「あらゆるものに対して」コードを含むクラスがひどく悪い習慣であることを知っています (そして、Symfony Book と Symfony Cookbook 全体のコントローラーは実際にそのように見えます)。作成するのは簡単ですが、維持するのは不可能です。そして、コードを分離しなければならない状況に陥った場合は、非常に楽しいものになります。しかし、これらの本は主に初心者を対象としているため、わかります。

では、実際にEntity Type Managersを作成するにはどうすればよいでしょうか。彼らはまったく行くべき道ですか？

Imageエンティティがあるとします。削除、更新、サムネイル サービスを呼び出してサムネイルを作成するには、 ImageManagerが必要です。その場所はどこですか? ディレクトリ構造のどこに属していますか? サービスを注入する必要があるため、マッピングされていないエンティティにすることはできません。

ベスト プラクティス クックブックの記事では、このようなことは何も言及されていません。

Answer 1

FOSUserBundle がそのコードを構造化する方法を見てみましょう。

User エンティティのストレージの知識を必要としないことを行う UserManager と、前者を拡張し、ストレージ層の知識を必要とすることを行う別のUserManagerがあります(EntityManager が注入されるため、例）。は、コントローラーから呼び出すことができるサービスとして定義されています。FOSUserBundle/ModelFOSUserBundle/DoctrineFOSUserBundle/Doctrine/UserManager

この構造の良いところは、テストが非常に簡単になることです。の単体テストはFOSUserBundle/Model/UserManager非常に軽量で、教義のモックを必要としません。の単体テストFOSUserBundle/Doctrine/UserManagerは、ドクトリンが嘲笑される場所です。

Answer 2

この種のベスト プラクティスがあるかどうかはわかりませんが、これを行うときは常にマネージャーをPath\To\MyBundle\Manager名前空間に配置します。同じことを行うサードパーティ ベンダーのプロジェクト内で見つけた唯一の例は、ElasticaBundleです。

重要なことは、マネージャーをサービスとして定義し、必要な依存関係を注入することです。テストを容易にし、必要に応じて後で個々のコンポーネントを交換しやすくするために、マネージャを実際のクラスではなくインターフェースに依存させてみてください。

RepositoryManager上でリンクした ElasticaBundle でクラスが行うように、マネージャーにすべてのパブリック メソッドを定義するインターフェイスを実装させることも非常に良い考えです。