[TYPO3-mvc] Persistence of value objects

[Jochen Rau]

Hi Dennis,

On Thu, Apr 19, 2012 at 06:51:05PM +0200, Dennis Ahrens wrote:
> In the past i had problems to identify value objects at all. The
> main problem for me was the connection to the database and the way
> TYPO4 v4 handles persistence.
> "Why the hell do they have a uid? Okay, without uid -> no relation -
> makes sense... But why do i distingush than? Ah, of course, because
> they do not really have an identity - but with a uid they obviously
> have... strange..."

I had the same feeling. Now, everything makes sense to only have Objects
(=Entities) with an intrinsic identity but a clear distinction between
Concept and Representation.

> >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.

> 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 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.

> >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 do not follow the FLOW3 project that closely - but in general
> extbase should go into the same direction.

I cannot agree more with you. They have to be in sync especially when it comes
to fundamental principles.

Thanks for you feed-back.

-Jochen