Replies: 2 comments 1 reply
-
I wouldn't talk about "logic" but about "hierarchy", however I agree with the need of "intermediate" superclasses. |
Beta Was this translation helpful? Give feedback.
-
I would add the Classes AssetEvent, ContractDefinitionEvent, ContractNegotiationEvent, PolicyDefinitionEvent and TransferProcessEvent. The internal PayLoad class i would move to the intermediate superclasses, with every variable the childs share. And if needed the CHilds for example AssetCreated could extend this PayLoad class. Also the ChildClasses need to extend the Payload class of the "intermediate" superclass. I would start with an example for AssetEvent if this is okay? Or will be their any conflicts with your adding of synchronouse event publishinh work? @ndr-brt |
Beta Was this translation helpful? Give feedback.
-
At the current state of the Event Framework all actual event class like TransferProcessRequested, AssetCreated and so on are extending directly the class Event.
Mabey it could be added more logic to the Events. Like a class TransferProcess between TransferProcessRequested and Event, Because at the moment i try to react on every Event referenced to TransferProcess and my Code looks like a disaster.
I have many if clauses or a big or-condition to find every event in relation to get to TransferProcesses. And to get the Payload of this Events(TransferProcessProvisioned, TransferProcessFailed, ...) is also terrible in my opinion because you have to cast the payload to specificEventclass.Payload class.
If i miss sth. and their is a better way to group this events mabey you could help me. Or you supporting the idea to add more logic to the Event Framework Event classes.
Beta Was this translation helpful? Give feedback.
All reactions