3

DoctrineのAPIが言うように:

EntityRepository は、エンティティを取得するための一般的なメソッドとビジネス固有のメソッドを備えたエンティティのリポジトリとして機能します。

このクラスは継承用に設計されており、ユーザーはこのクラスをサブクラス化して、エンティティを見つけるためのビジネス固有のメソッドを使用して独自のリポジトリを作成できます。

しかし、エンティティを保存するためのビジネス ロジックを配置する適切な場所はどこでしょうか?

  1. エンティティ自体に正しいコンストラクターを配置しますか?
  2. リポジトリにも入れますか？
  3. 新しいエンティティを挿入することは、データを入力できるようにする「フォーム」に非常に関連しているため、多かれ少なかれコントローラーにあるはずですか?
  4. コントローラーのヘルパークラスを作成して、ヘルパークラスによって作業が行われ、コントローラーを爆破しないようにしますか?
  5. この質問を書いているときに、他に何か思い浮かびませんでしたか?

コントローラーを爆破することから遠く離れた解決策を好みます。現在、どこに配置すればよいかわからないため、さまざまなコントローラーによって呼び出されるヘルパー クラスを作成しました。

4

3 に答える 3

4

UserManager私の解決策は、などのマネージャーのレイヤーを使用することです。このレイヤーは、サービスレイヤーパターンArticleManagerの実装です。

managerレイヤーは、モデルオブジェクトの永続化とフェッチに関連するすべてを非表示にします。つまり、このレイヤーを使用するオブジェクトは、モデルの保存方法と保存場所を気にせず、アプリケーション全体を書き直すことなくいつでも変更できます。

したがって、たとえば、コントローラーはDoctrineについて何も知りません。今日は永続性のためにDoctrineORMを使用しているかもしれませんが、明日はDoctrineODMまたは単なるファイルかもしれません。後で何に切り替えても、アプリケーション全体ではなく、マネージャー層のみを変更する必要があります。

典型的な方法は次のUserManagerとおりです。

  • find($id)
  • findBySomething($something)
  • save(User $user)
  • delete(User $user)

また、マネージャーレイヤーは、モデルオブジェクトレベルだけでは制御できないシステムのドメインロジックを制御します。たとえば、UserManagerを保存するように求められた場合、が空でないUserかどうかを確認し、それをエンコードしてに設定します。モデルはサービスに依存してはならず、このタスクにはパスワードエンコーダサービスが必要であるため、このロジックをモデルクラスに保持することは意味がありません。$user$plainPassword$passwordUser

マネージャ層の背後でリポジトリを使用するかどうかはあなたの選択です。リポジトリは、取得方法のためだけに使用できます。しかし、私はそれらを使用しないことを選択しました。なぜなら、それらは私にとって何の利益もなく、少し複雑さを増しているからです。すべての永続性のものはマネージャーレイヤーの背後に隠されているので、後で好きなようにリファクタリングできます。

于 2013-03-16T10:19:23.137 に答える
1

すべてのsf2開発者が気にする必要のあるベストプラクティスに関連するものを除いて、エンティティを保存するための特定のルールはありません。

  1. 私のエンティティ自体に正しいコンストラクターを配置しますか？(You've to keep your entities simple and do not let them know about the persistence layer)

  2. リポジトリにも入れますか？(Mainly used for retrieving Entities)

  3. 新しいエンティティの挿入は、データの入力を可能にした「フォーム」と非常に関連しているので、多かれ少なかれコントローラーに含める必要がありますか？Inserting entities in not related to "form". It's ok to put it in your controller, but if you have many lines of code that create and persist your entities, You should then put a shortcut method which contains this logic. (You can also add a base controller for common methods).

  4. コントローラーのヘルパークラスを作成して、作業がヘルパークラスによって行われ、コントローラーを爆破しないようにしますか？依存性注入コンテナ(Take a look at the , it allows you to create a service for this purpose).

于 2013-03-16T10:09:29.813 に答える
0

ここで DIC が機能します。あなたのエンティティ自体は、バックグラウンドでのDBについて知らずに、愚かでなければなりません..コントローラーは軽量のままでなければなりません..そのために、依存性注入を使用して「サービス」を作成できます。

http://symfony.com/doc/master/book/service_container.html

ヘルパークラスで同様のことを行っていると考えてください。symfony の方法で微調整することができるかもしれません。

-クリス

于 2013-03-16T09:54:06.343 に答える