How to store the modifier user in a Symfony 2 entity

Question

I would like to have entities log the user (preferably his ID) that has most recently modified an entity. I think a pretty entity has a getModifier() method but has no setModifier() since that is handled by the class as an internal affair. I'd use some prePersist to update the entity with the user ID. So here are the two main questions:

1) Technically, how can I get the current user's ID inside an entity's prePersist?

2) Philosophy. I have found lots of answers that advise me to rethink my model not to be dependent on anything other than the data stored in it. I fail to see how the isolating entities from the rest of the world is sane: see two contrasts here on what is allowed for entities to do. Accessing a service to get a folder-name where some cached output can be stored is thought illegal; while writing to the filesystem with file abstraction classes is OK; I think the latter makes more assumptions about filesystems. Accessing the current user's identity is considered illegal; while putting current timestamps on the entity is OK; so the concept of a (possibly missing) user is bad while the concept of time is good? If the concept about not relying on anything other than the model itself is valid then how does anyone dare to use DateTime functions? (Please don't say that the services of PHP are always accessible, because some missing settings/extensions can easily cause these to fail.) I fail to see how to build any logic into entities while adhering to such strict restrictions, and how to avoid that entities end up to be nothing more than data (by this level of encapsulation and information hiding, this entity model offers me nothing over mere arrays). Could anyone point me what is the particular difference between those elements of the model's environment that must not be used and those that are considered legitim?

Answer 1

Let me split my answer in two parts:

Regarding 1)

You cannot. This would be very difficult for doctrine to achieve. While your question in 2) will be discussed below, let's say it like this: The common understanding is that models don't know about stuff as services but are used by services to make them reusable.

Why not combine setters and add a $user attribute to the combined setter, setting the modifier like this:

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

Of course you could also add the user to each setter.

And, of course, there are other ways. You could e.g. add a not persisting property activeUser and on prePersist use this or if not set throw an exception.

Regarding 2)

First, let's acknowledge there are two schools of thought. One is that models can hold business logic and may use other classes, but should not depend on the bigger picture, meaning they should not get complex objects from callers. The other (and I'm in this one) is that models should be dump data stores which should not contain business logic at all.

Both think that models should be more or less stupid. If you have a look at active records (used by symfony 1 and RoR) you see another concept of models who know their context and e.g. have to know about the database. While this has some advantages (like you can save a model from inside itself or you can make it aware about which user acts on it right now) you also got great disadvantages (like a model depending on a great context, making it hard to migrate it or even test ist).

Doctrine does not use Active Record, so you will have to live with this more or less "dump objects" or exchange the ORM with one that uses the concept of Active Records (like Redbeanphp).