2

エンティティに、エンティティを最後に変更したユーザー (できれば彼の ID) をログに記録させたいと考えています。きれいなエンティティには getModifier() メソッドがありますが、クラスによって内部問題として処理されるため、 setModifier() はありません。prePersist を使用して、エンティティをユーザー ID で更新します。そこで、主な質問は次の 2 つです。

1) 技術的には、エンティティの prePersist 内で現在のユーザーの ID を取得するにはどうすればよいですか?

2) 哲学。モデルがそこに保存されているデータ以外のものに依存しないように再考するようにアドバイスする多くの回答を見つけました。世界の他の地域から隔離しているエンティティがどのように正気なのか、私にはわかりません。エンティティに許可されていることについて、ここで 2 つの対比を見てください。キャッシュされた出力を保存できるフォルダー名を取得するためにサービスにアクセスすることは違法と見なされます。ファイル抽象化クラスを使用したファイルシステムへの書き込みは問題ありません。後者はファイルシステムについてより多くの仮定をしていると思います。現在のユーザーの ID へのアクセスは違法と見なされます。エンティティに現在のタイムスタンプを付けても問題ありません。(行方不明の可能性がある) ユーザーの概念は悪いのに、時間の概念は良いのでしょうか? モデル自体以外に依存しないという概念が有効である場合、DateTime 関数をあえて使用する人がいるでしょうか? (PHP のサービスが常にアクセス可能であるとは言わないでください。一部の設定/拡張機能が欠落していると、簡単に失敗する可能性があるためです。)このような厳格な制限を順守しながら、エンティティにロジックを構築する方法がわかりません。エンティティがデータ以上のものにならないようにします (このレベルのカプセル化と情報の隠蔽により、このエンティティ モデルは単なる配列に勝るものはありません)。使用してはならないモデル環境の要素と正当と見なされる要素との特定の違いは何ですか? PHP のサービスは常にアクセス可能であると言えます。一部の設定/拡張機能が欠落していると、簡単に失敗する可能性があるためです.) 私は、そのような厳格な制限を守りながらロジックをエンティティに組み込む方法と、エンティティの終了を回避する方法を理解していません。データにすぎません (このレベルのカプセル化と情報の隠蔽により、このエンティティ モデルは単なる配列に勝るものはありません)。使用してはならないモデル環境の要素と正当と見なされる要素との特定の違いは何ですか? PHP のサービスは常にアクセス可能であると言えます。一部の設定/拡張機能が欠落していると、簡単に失敗する可能性があるためです.) 私は、そのような厳格な制限を守りながらロジックをエンティティに組み込む方法と、エンティティの終了を回避する方法を理解していません。データにすぎません (このレベルのカプセル化と情報の隠蔽により、このエンティティ モデルは単なる配列に勝るものはありません)。使用してはならないモデル環境の要素と正当と見なされる要素との特定の違いは何ですか? そして、エンティティが単なるデータになることを回避する方法 (このレベルのカプセル化と情報の隠蔽により、このエンティティ モデルは単なる配列に勝るものはありません)。使用してはならないモデル環境の要素と正当と見なされる要素との特定の違いは何ですか? そして、エンティティが単なるデータになることを回避する方法 (このレベルのカプセル化と情報の隠蔽により、このエンティティ モデルは単なる配列に勝るものはありません)。使用してはならないモデル環境の要素と正当と見なされる要素との特定の違いは何ですか?

4

1 に答える 1

2

私の答えを2つの部分に分けてみましょう：

1)について

それはいけません。これは、ドクトリンが達成するのは非常に難しいでしょう。2) の質問については以下で説明しますが、次のように言いましょう。一般的な理解は、モデルはサービスとしてのものを認識していないが、サービスを再利用可能にするためにサービスによって使用されるということです。

セッターを結合し、結合されたセッターに $user 属性を追加して、修飾子を次のように設定してみませんか。

public function setAttributes($user, $attr1, $attr2)
{
    $this->modifier = $user;
    $this->attr1 = $attr1;
    $this->attr2 = $attr2;
}

もちろん、ユーザーを各セッターに追加することもできます。

もちろん、他の方法もあります。たとえば、永続化されないプロパティactiveUserを追加し、prePersist でこれを使用するか、設定されていない場合は例外をスローすることができます。

2)について

まず、2 つの考え方があることを認めましょう。1 つは、モデルはビジネス ロジックを保持でき、他のクラスを使用することもできますが、全体像に依存してはならず、呼び出し元から複雑なオブジェクトを取得してはならないということです。もう 1 つは (そして私もこれに参加しています)、モデルはビジネス ロジックをまったく含めてはならないダンプ データ ストアにする必要があるということです。

どちらも、モデルは多かれ少なかれ愚かであるべきだと考えています。アクティブなレコード (symfony 1 と RoR で使用) を見ると、コンテキストを知っているモデル、たとえばデータベースについて知っている必要があるモデルの別の概念がわかります。これにはいくつかの利点があります (モデルを内部から保存できる、現在どのユーザーがモデルを操作しているかをモデルに認識させることができるなど) 一方で、大きな欠点もあります (モデルが優れたコンテキストに依存するため、移行が困難になるなど)。それまたはテストイスト）。

Doctrine は Active Record を使用しないため、多かれ少なかれこの「ダンプ オブジェクト」を使用するか、ORM を Active Records の概念を使用するもの ( Redbeanphpなど) と交換する必要があります。

于 2012-10-14T19:56:16.933 に答える