什么情况下可以存储域实体的可变属性值对象？ [英] Is it okay to store a domain entity's mutable properties as a value object?

问题描述

有，我想能够改变，并通过在我UserEntity的某些部分，并且有应保持不变某些部分。

There are certain parts of my UserEntity that I would like to be able to change and pass around, and there are certain parts that should remain constant.

例如，我从来没有想改变我的UserEntity的ID，但事情如电子邮件或密码可能经常发生变化，并且可以通过其他物体UserEntity之外使用为好。

For example, I NEVER want to change my UserEntity's id, but things like email or password may change often, and can be used by other objects outside of the UserEntity as well.

创建UserEntity当这一个实例会。由于UserEntity不能没有一个id存在，我的控制器可以创建一个对象的UserData将标准化UserEntity属性。映射器在数据库中创建了一个实体后，它会创建一个新的UserEntity并通过在构造函数中的ID名和userdata对象。

One instance of this would be when creating a UserEntity. Since a UserEntity cannot exist without an id, my controller could create a UserData object that would standardize the UserEntity properties. After the mapper creates an entity in the db, it would create a new UserEntity and pass in the id and UserData object in the constructor.

在UserEntity需要像电子邮件或密码信息，它可以只是看它的UserData。

When UserEntity needs info like email or password, it can just look at its UserData.

似乎更便携，但是这是矫枉过正？有没有更好的解决办法？

Seems more portable, but is this overkill? Is there a better solution?

注意

• 我之所以认为这可能是好：可变字段的值需要标准化......有时需要围绕实体本身以外的地方通过这些字段。例如，之前已创建的实体。通过创建可以围绕我们提供一个标准化的点分配从任何地方这些值，以及东西，可以围绕该实体的外侧被传递要传递一个值对象

• The reason why I think this might be good: the values of the mutable fields need to be standardized...and sometimes these fields need to be passed around outside of the entity itself. For example, before the entity has been created. By created a value object that can be passed around we provide a standardized spot to assign these values from anywhere, as well as something that can be passed around outside of the entity.

通过标准化我的意思是，我的信息需要统一的，无论它的存在。例如，电子邮件需要永远是 N 的长度和格式无效，名称总是需要为 N 长度等我在这里的目标是，我希望能够在单点设置这些规矩 ......并且由于UserEntity的这些属性（易变的）实体本身以外的存在，有时候，他们可能会自立门户，以自己的值对象。

By "standardize" I mean that my information needs to be uniform, wherever it exists. For example, email needs to always be n length and in a valid format, name always needs to be n length, etc. My goal here is that I'd like to be able to set those "rules" in a single spot...and since these properties of the UserEntity (the mutable ones) exist outside of the entity itself, sometimes, they could potentially live on their own, in their own value object.

推荐答案

我不认为这是唯一正确的方法来做到这一点（不管你了解它是什么）......如果它是有道理的模式，那么它的声音对我好。我不知道，当你说许多这些领域中需要标准化和为什么不能做到的UserEntity的一部分，但无论你的意思是什么。这就是说，赔率是你可以做到你想没有一个完全独立的对象类做的事情。

I don't think there is "one true way" to do it (no matter what you read about it)... if it makes sense in your model, then it sounds good to me. I'm not sure exactly what you mean when you say "many of those fields need to be standardized" and why that couldn't be done as part of the UserEntity, but whatever. That said, odds are you can accomplish exactly what you're trying to do without an entirely separate object class.

评论/批判：

什么你的建议并没有真正附和了严格的对象的模式，即的UserData只是由东西都是真的属性UserEntity的，而且也为那些属性没有其他的基本关系。

What you are suggesting doesn't really go along with a strict "object" model, i.e. the UserData is just made up of things that are really attributes of UserEntity, and there's no other underlying relationship to those attributes.

我真的不知道你为什么会需要一个单独的对象是传递实体之外......如果你需要的数据，为什么你不能只是通过周围的UserEntity，并从那里访问它？你有什么需要将它传递给UserEntity构造不能很容易地在一个stdClass的实例一起收集数据，然后处理它UserEntity完成之前的数据怎么办？

I'm not really sure why you would need a separate object to pass around outside the entity... if you need the data, why can't you just pass around the UserEntity and access it from there? What do you need to do with the data before passing it to the UserEntity constructor that couldn't just as easily be accomplished with gathering the data together in an instance of stdClass and then processing it in UserEntity?

如果是我的话，我会做更多的东西像下面的（，比如说，创建新用户）：

If it were me, I'd do something more like the following (for, say, creating a new user):

<?
// 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());
?>

---

编辑解决提供了更多的信息：

---

Edit to address more information provided:

您说的这些属性UserEntity之外存在，并且它们可能生活在他们自己......你的意思是这些属性可以收集，使用和废弃，甚至没有被用于一个UserEntity对象吗？如果是这样的话，那么一个单独的对象将是完全适当的数据。如果不是这样，如果数据总是从属于一个现有或未来UserEntity，那么这些属性将永远不会自立门户从......让我们称之为观全球数据点。当你考虑整个系统作为一个整体，而不仅仅是每时每刻code，很可能是该数据属于UserEntity类。

You say these properties exist outside of the UserEntity, and they could potentially live on their own... Do you mean that these properties could be gathered, used, and discarded without even being intended for a UserEntity object? If that's the case, then a separate object would be entirely appropriate for that data. If not, if the data is always subordinate to either an existing or future UserEntity, then those properties will never "live on their own" from a... let's call it a "global data" point of view. When you consider the entire system as a whole, not just the code from moment to moment, it's likely that the data "belongs to" the UserEntity class.

对于静态方法，我看不出有什么特别的理由，以避免他们（明显），但每一个他自己。许多其它架​​构将是一个稍微复杂一些，但这里有一些选择：

As for static methods, I see no particular reason to avoid them (obviously), but to each his own. Many other architectures would be a little more complex, but here are some options:

1. 验证在构造函数中的数据。问题是，如果它不验证，你就必须删除数据库条目。难看。


2. 将数据库交互到构造函数，用数据验证一起。这可能会侵犯您的preferred对象模型，你就只需要检查对象的状态，一旦它的创建（即设置了公共财产 $这个 - ＆GT;状态='错误'; 或类似的东西告诉你，不好的事情发生了，你必须处理）。


3. 创建一个独立的功能来验证数据。难看，因为这是的具​​体涉及UserEntity和/或它的数据的功能。


4. 或者，只需要创建一个单独的UserData对象，就像你建议，并用它做。就像第2步，你必须有某种 $状态属性来指示验证失败。

1. Validate the data in the constructor. The problem is that if it doesn't validate, you'll have to remove the database entry. Ugly.
2. Move database interaction into the constructor, along with data validation. This could violate your preferred object model, and you'll just have to check the status of the object once it's created (i.e. set a public property $this->status = 'error'; or something like that to tell you that something bad happened that you'll have to handle).
3. Create a standalone function to validate the data. Ugly, because this is a function that's specifically related to UserEntity and/or its data.
4. Or, just create a separate UserData object like you've suggested and be done with it. Much like step # 2, you'll have to have some sort of $status property to indicate a failed validation.

这篇关于什么情况下可以存储域实体的可变属性值对象？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！