は...、それは私にはいいですね。 「これらのフィールドの多くは標準化する必要があります」と、なぜUserEntityの一部として行うことができないのか、ということは何を意味するのか正確にはわかりません。つまり、完全に別々のオブジェクトクラスなしで、あなたがしようとしていることを正確に達成できるということです。
コメント/批評：
UserDataのは本当にUserEntityの属性、および他はありませんされているもので構成され、すなわち、何が示唆されていることは、本当に、厳格な「オブジェクト」モデルと一緒に行きませんそれらの属性との根本的な関係。
エンティティの外を渡すために別のオブジェクトが必要なのは本当にわかりません。データが必要な場合は、なぜUserEntityを渡してそこからアクセスできないのですか？ StdClassのインスタンスでデータをまとめてUserEntityで処理するだけでは簡単にできないUserEntityコンストラクタに渡す前に、データで何をする必要がありますか？提供より多くの情報に対処する
<?
// assume an appropriately defined UserEntity class...
// I'm using stdClass just to keep the parameters together to pass all at once
// I'm assuming some basic user data passed from the browser
$user_data = (object) array(
'email' => $_REQUEST['email'],
'name' => $_REQUEST['name'],
'password' => $_REQUEST['password'],
'confirm_password' => $_REQUEST['confirm_password']
);
/*
validateData is static so it can be called before you create the new user
It takes the $user_data object to validate and, if necessary, modify fields.
It also takes a $create flag which indicates whether the data should be
checked to make sure all of the necessary fields are there to create the user
with. This allows you to call it on update with the $create flag unset and it
will pass validation even if it's missing otherwise required fields.
It returns $result, which indicates pass or failure, and the potentially modified
$user_data object
*/
$create = TRUE;
list($result, $user_data) = UserEntity::validateData($user_data, $create);
// equivalence allows you to pass back descriptive error messages
if ($result === TRUE) {
// create the user in the database, get back $user_id...
$user = new UserEntity($user_id, $user_data);
}
else {
// return error to user
}
// access user data either individually, or if you want just make a getter
// for the entire group of data, so you can use it just like you would a
// separate UserData object
send_double_opt_in($user->getUserData());
?>
編集：それは私だったら
は、私は（新しいユーザーを作成し、たとえば、のために）以下のようなより多くの何かをしたい
を
あなたはこれらのプロパティがUserEntityの外に存在し、潜在的にそれら自身で生きている可能性があると言います...これらのプロパティはUserEntityを意図していなくても集められ、いいえ。そうであれば、別のオブジェクトがそのデータに完全に適しています。そうでない場合は、データが常に既存のUserEntityまたは今後のUserEntityのいずれかに従属する場合、それらのプロパティは決して「自分自身で」生き残ることはできません。システム全体を、コードだけでなく全体として考えると、データはUserEntityクラスに属している可能性があります。
静的メソッドに関しては、私はそれらを（明らかに）回避する特別な理由はないが、各自のものには明らかである。他の多くのアーキテクチャは少し複雑ですが、いくつかのオプションがあります：
- コンストラクタ内のデータを検証します。問題は、検証しないと、データベースエントリを削除する必要があることです。醜い。
- データ検証とともに、データベースのやり取りをコンストラクタに移動します。これは、あなたの好みのオブジェクトモデルに違反する可能性があります。作成したオブジェクトの状態を確認するだけです（つまり、パブリックプロパティ
$this->status = 'error';などを設定して、何か悪いことが起こったことを伝えなければならないことを伝えてください） 。
- データを検証するためのスタンドアロン機能を作成します。なぜなら、これはUserEntityやそのデータに具体的に関係する関数なのですから。
- または、提案したように別のUserDataオブジェクトを作成して、それを完了してください。ステップ＃2と同じように、検証に失敗したことを示すために、ある種の
$statusプロパティを持っていなければなりません。
あなたのIDフィールドはプライベートで、あなたのUserEntityの内部にはget（）アクセスしかありません。 –
これは考えているでしょう:)しかし、変更可能なプロパティの値設定子は値オブジェクト – johnnietheblack
エンティティオブジェクトの電子メール、パスワード、および他のすべてのフィールドを持つだけで何が問題になりますか？別々のデータオブジェクトに与えるメリットは何ですか？ –