2016-04-23 3 views
0

私はDDDアプローチの小さなプロジェクトを開始しています。私は、プレーンなPHPでエンティティとバリューオブジェクトを使ってドメインモデルを作成しました。エンティティには関連付けの参照があります。私のケースでは、彼が所属するTeamsのコレクションを持つEmployeeエンティティがあり、それらをEmployee::teamsのプロパティに保持します。すべてが素晴らしい起こっている、私はDoctrine2リポジトリから配列として関連付けられたエンティティコレクションを取得します。

私はリポジトリから(DoctrineのEntityManager::findAll()で)Employee Sをフェッチ代わりなどのリポジトリがSymfony2のとDoctrine2層に実装されるためにYAMLで団体、インタフェース、とそれらのエンティティのマッピングを作成しましたTeamの配列の私はそれらのチームとPersistentCollectionを受け取る。これはPHP7で構築されており、Employee::getTeams()の戻り値の型はarrayです。したがって、私は重大な例外を受けています。 いくつかの外部リスナー(ドメインファイルで混乱しないようにSymfonyレイヤーのみ)やその他のコアメカニズムを使って配列に変換する方法はありますか?

ありがとうございました。

+0

例外メッセージは何ですか。 –

+0

@Alok例外は、PHPの 'TypeError'です:** Employee :: getTeams()の戻り値は、配列型でなければならず、**返されたオブジェクトでなければなりません。私は 'PersistentCollection :: toArray()'を呼び出すことができますが、可能であれば、私はDoctrine ORM( 'PersistentCollection'を含む)を使用することを提案しているので、そのような型を私のドメインに残さないことを望みます。 –

+0

自動生成エンティティ?すべてのonToManyアソシエーションに '\ Doctrine \ Common \ Collections \ Collection'の戻り値の型があるためです。 –

答えて

0

あなたは

/** 
* @return Team[] 
*/ 
public function getTeams(): array 
{ 
    return $this->teams->toArray(); 
} 

を書くことができますので、それはtoArray()メソッドを持っている。しかし、私はあなたがPhpStormのような優れたIDEを使用している場合は、それはそれを理解します

/** 
* @return Team[]|ArrayCollection 
*/ 
public function getTeams() 
{ 
    return $this->teams; 
} 

を好むのArrayCollection
http://www.doctrine-project.org/api/common/2.5/class-Doctrine.Common.Collections.ArrayCollection.html

を取得ArrayCollectionのように正しくオートコンプリートするにはTeam i fを作るforeach ($employee->getTeams() as $team) {...

ArrayCollectionはプレーンな配列より強力です。たとえば、あなたは、フィルタリングし、それらを注文すると、あなたはDDDの質問のように見えるが、技術的なされません全ての項目
http://docs.doctrine-project.org/en/latest/reference/working-with-associations.html#filtering-collections

0

クバ、

をロードする必要はありませんので、Doctrineは最適化されたSQLを行いますすることができますPHP実装の詳細に関する質問。 しかし、私はあなたの設計に飛び込み、あなたのドメインのためのよりよい解決策を見つけようとしてください。あなたは、従業員とチームの関係をモデル化するために欠けています。それをチームで従業員と呼んでみましょう。あなたがしたやり方は、ARが別のARを参照するように強制して、従業員がチームのライフサイクルを管理するという方法です。これは当てはまらないかもしれませんが、特定のシナリオでは、別の俳優がチームのステータスを変更し、チームARを介して従業員の不変条件を破る可能性があります。このため、ARを作成して別のARライフサイクルを管理する場合、この依存関係をリポジトリから見つけるべきではなく、集約のルートは集約ARの周囲で不変でなければなりません。 言及するにはいくつかの懸念がありますが、シンプルに保つためには、あなたが欠けている概念をモデル化してください。EmployeeInTeamまたはそれを呼びたいものは何でも構いません。これは、従業員とチームの概念的なアイデンティティーを参照して将来的に安全に削除できるようにするために、チーム内の従業員と従業員のチームを照会することができます。 一貫性を維持するためにフレームワークまたはDBが必要な場合は、DDDを実行していません。テクノロジではなくオブジェクトだけを使用します。

よろしく、 セバスチャン。

+0

確かに、ドメインモデルを構築し、ビジネスロジックを実装しましたが、今はDBレイヤーのDoctrine、ビュー表示のTwigなどと一緒にSymfonyと統合したいと思っていますあなたの建設的なコメントをありがとうございますが、この 'EmployeeInTeam'オブジェクトを指して何を意味したのか正確には分かりません。それは何ですか?そして私はそれをどのように使うべきですか? –

+0

EmployeeInTeamは関係をモデル化します。 Vaugh Vernon氏が集計の設計について読んだ場合、employee :: teamsは良い設計上の決定ではないことがわかります。 –

関連する問題