-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
2019/08/09/domain-events #7
Comments
Nice article and approach but how does it deal with missing ID issue? Safe approach would be to work with uuid's instead of id's, which may exist during preUpdate and prePersist + call the events twice (somehow), so you can hook to preUserCreated and postUserUpdated if you want to (maybe via decorator that would append |
Good catch, I will update my example! |
Hello, about that:
As I used to use that and haven't met any issue yet, I'm wondering if you could share with us a list of potential limitations? Thanks for your article |
Hello @mickaelandrieu, The biggest limitation is that you have to call Unit of work to re-compute changeset if you modify an entity or create a new one. It is not literally impossible to do, but then your listeners know how the calling context, and it is a pretty big issue regarding code simplicity and ability to re-use. Regarding relationships, I remember having such an issue, but it was a long time, I don't have the details at hand anymore. I will try to dig in my memories! |
Never had an issue (never had to recompute changeset) although i noticed someone recently posting some doctrine listener on Sf slack with that being called, after longer discussion it turns out to be needed, but only if you modify a not-yet-tracked entity. For example: we have entity A and entity B, A is oneToMany B, now if we want to modify A via listener when B is modified, if we just modify something in A it will not be noticed by unit of work - because it isn't considering it being modified during current |
It may have changed, because I definitely remember it being needed a few years ago. It may also depend upon which events you use, and how (lifecycle hooks, or listeners...). |
Hmmm, are those Events in your implementation stored anywhere? |
Not here, they are just temporary in a PHP array. You could easily persist those in PS: sorry for the very slow answer! I somehow lost track of notifications. |
@romaricdrigon How would this approach work if the Entity needed knowledge of a state of a model outside of the current entity? For example.. A user who's account is not active, who places as order. You may want to raise a domain event for something like, rather than jsut simple, created update removed. |
Who call dispatchCollectedEvents method? |
sorry for the late answer - I got kind behind my blog.
Just below the code snippet options are detailed: either it has top be called manually (from controller, etc.), either by a Symfony listener listening to |
Hi, thank for the great article. I would like to read your opinion about our solution of dispatching collected events. The solution doesn't require manually dispatching of events or automated dispatching during I thing the problem that we can't call The solution is to decorate
|
Hello @ludekbenedik If that works for you, I think it is a quite good and quite convenient solution! |
I'm wondering how to deal with dispatch collected domain events in the same transaction?
|
You can create a subscriber with postPersist, preUpdate, postUpdate and postDelete event listeners (only these events are executed in transaction). In the listeners you use the connection from the entity manager from the event and insert serialized events to a table. |
thank you for suggestion, it looks nice. But I have found inspiration here: Thanks anyway. |
Domain events are great. I wouldn't recommend your "How they are thrown" approach.
In short, this approach doesn't feel adequate or suitable for domain events. Doctrine does provide EntityListeners which gives fine-grained access to events - incase that is part of your concern about using Doctrine events. The main difference between this approach and using Doctrine's event system is that:
Finally, you don't want to be firing all events in |
Hellow. |
Please comment below!
Comments will automatically be published on the blog, too.
The text was updated successfully, but these errors were encountered: