Using Doctrine 2 / DataMapper, how do I persist new entities in the domain layer?

Question

I have a tree-like structure with a couple of entities: a process is composed of steps and a step may have sub-processes. Let's say I have 2 failure modes: abort and re-do. I have tree traversal logic implemented that cascades the fail signal up and down the tree. In the case of abort, all is well; abort cascades correctly up and down, notifying its parent and its children. In the case of re-do, the same happens, EXCEPT a new process is created to replace the one that failed. Because I'm using the DataMapper pattern, the new object can't save itself, nor is there a way to pass the new object to the EntityManager for persistence, given that entities have no knowledge of persistence or even services in general.

So, if I don't pass the EntityManager to the domain layer, how can I pick up on the creation of new objects before they go out of scope?

Would this be a good case for implementing AOP, such as with the JMSAopBundle? This is something I've read about, but haven't really found a valid use case for.

Answer 1

If I understand your problem correctly (your description seems to be written a bit in a hurry), I would do the following:

• mark your failed nodes and your new nodes with some kind of flag (i.e. dirty flag)
• Have your tree iterator count the number of failed and new nodes
• Repeat tree-iteration / Re-Do prcocess as often as you want, until no more failed or new nodes are there that need to be handled

Answer 2

I just found a contribution from Benjamin Eberlei, regarding business logic changes in the domain layer on a more abstract level: Doctrine and Domain Events

Brief quote and summary from the blog post:

The Domain Event Pattern allows to attach events to entities and dispatch them to event listeners only when the transaction of the entity was successfully executed. This has several benefits over traditional event dispatching approaches:

• Puts focus on the behavior in the domain and what changes the domain triggers.
• Promotes decoupling in a very simple way
• No reference to the event dispatcher and all the listeners required except in the Doctrine UnitOfWork.
• No need to use unexplicit Doctrine Lifecycle events that are triggered on all update operations.

Each method requiring action should:

1. Call a "raise" method with the event name and properties.
2. The "raise" method should create a new DomainEvent object and set it into an events array stored in the entity in memory.
3. An event listener should listen to Doctrine lifecycle events (e.g. postInsert), keeping entities in memory that (a) implement events, and (b) have events to process.
4. This event listener should dispatch a new (custom) event in the preFlush/postFlush callback containing the entity of interest and any relevant information.
5. A second event listener should listen for these custom events and trigger the logic necessary (e.g. onNewEntityAddedToTree)

I have not implemented this yet, but it sounds like it should accomplish exactly what I'm looking for in a more automated fashion that the method I actually implemented.