[TYPO3-mvc] Persistence of value objects

[Dennis Ahrens]

Hi Jochen,

On 19.04.2012 22:33, Jochen Rau wrote:
>>> Recently I spent some time thinking about the difference between these
>>> two DDD building blocks. I came to the conclusion that there is none.
>>> Eric Evans argues from a technical standpoint. The promise is, to
>>> differentiate between Entities and ValueObjects will lead to a
>>> performance gain and a simpler system. In fact it is quite the opposite.
>>> And from a Domain perspective, we don't need to make such a distinction.
>>
>> Just read the part in Evans book again and i disagree that there is
>> no difference in general. From the conceptual point of view the
>> disjunction of both building blocks makes sense.
>
> I still lack a good example, where it makes sense.

IMO Stephan gave a bunch of good examples this morning.

>> But in fact we are in the world of PHP where the runtime is always
>> just one request and we have to persist everything at the end of
>> each request. In this environment the value object is not cheaper
>> than the entity - we have to query the database for an existing
>> instance. But it is also not much more expensive, it's "just" +1
>> query (and if the query matches an object it's equal).
>
> The argument made by Evans is to avoid the overhead of tracking object
> duplication in memory. Now, having ValueObjects, we have to add another
> query. That might save a lot of memory and processor power. But what, if
> we can avoid the tracking overhead in the fist placeThat might save a
> lot of memory and processor power. But what, if we can avoid the
> tracking overhead in the first place??

I think there are possible solutions available. E.g. you can have a 
database column that stores the hash made of the data included in the 
object. This column can be set unique. If a value object should be 
persisted you just fire a insert query. If the database beefs, because 
the hash is know - just do nothing. The hash may be used as identifier, 
too - have not thought the stuff regarding collision until the end now - 
but this is just an example...

The fact is that those apporaches do not match the current DB setup of 
TYPO3 v4. And that's the problem.

>> I currently identified my first value object that makes sense IMO -
>> let me explain what and why i think that it makes sense to use a
>> value object here instead of an entity. I stick near to the TYPO3
>> universe...
>>
>> One Person have 0..n addresses. There are a few thousand instances
>> that share five different addresses, because they belong to our
>> university and work at one or more of our locations. In addition any
>> other external person can be added with any address.
>>
>> If we make addresses an entity we *must* have set of all addresses
>> our editors have to take care of, if we'd like to keep the number of
>> redundancy addresses small.
>>
>> Editors can not just add a person, entering a few addresses and
>> save. They have to search for existing addresses to add or create
>> new. If it's modelled to reach this using IRRE we'll have a few
>> thousand objects in the database that cover the same address with
>> just different uids.
>
> In fact, this is a very good example for *not* using ValueObjects.
> Regarding addresses there are two domain related problems to solve:
>
> - assigning a place to a person, and
> - avoid duplication of its representation.
>
> You could let the user select an existing place (by offering a
> selection of their representations = addresses). The user can also add a
> new place and enter a new representation. But you cannot solve the
> problem of duplication by just declaring the address to be a
> ValueObject. On the technical level it only ensures that there is only
> one address with the same hash over the properties. But what if there is
> a small typo? Or even 3? Or both? The problem of de-duplication has to be
> solved on the UI level, not in the Domain Model.

You are right - the main problem i described is assigned to the 
multiselect form ui of the TYPO3 backend. A object with four properties 
is hard to identify with one label.
Nevertheless i think that in my domain the address is a value object. I 
just want to assign several addresses to persons and the only use is to 
show them formatted with HTML. There is a big redundancy of same 
addresses on the one side and the also high amount of different 
addresses on the other side. And i don't care of addresses, when not 
dealing with persons. They don't need an identity.

>>> So, I propose to deprecate the use of ValueObjects. In addition, we
>>> should come up with some guide how to model the domain with the
>>> distinction between concept and representation in mind.
>>>
>>> What do you think?
>>
>> I think that in general it makes sense to distinguish between both
>> object types. I also think that it is a big task to tackle TCEMain.
>> Using hooks to match the requirements of value objects is not
>> reliable IMO.
>
> Does it really make sense to add hooks, checks, database queries? I
> doubt it.

I think it makes sense to have good technical solution for the 
conceptual approach - if we don't want to cut the concept at this point.
As mentioned above and yesterday the problem in my eyes is the legacy 
code that currently handles persistence in the core. That makes it hard 
to find a good/clean solution here.

regards
Dennis