State versus Event
While designing your data model, you not only have to think about the actual structure of the data, but also about its semantics (behavior). Currently, Qeo offers two preconfigured behaviors for you to choose from: State and Event. For additional information on states and events, refer to System Description.
Example
A small example may illustrate best when to use Events versus States. Whether a door is open or closed, is definitely a State: any door is always either open or closed, so the property can be queried at any time. On the other hand, the fact that someone is passing through a door (cfr the optical sensors that ring a bell when you enter a shop) is an Event: it is a discrete spike, and the same condition (someone passing through the door) is no longer valid one moment earlier or later (i.e. before or after the person has passed through the door).
Another way to look at it is that Events are the derivative of State: whenever the number of people in a room (State) changes, that means someone passed through the room's door (Event).
Use State or Event?
In general, it is better to model data in the system as State instead of Event: in most cases, the subscribing application will want to build an internal model of the system's global state. By modeling data as State, Qeo will build this model on behalf of the application, whereas modeling data as Events (i.e. state transitions) forces the subscribing application to rebuild the state itself based on the events. In addition, the fact that late joiners are not supported by Events makes it hard to build a full model of the system's state: it is hard to apply deltas (Events) to a state if one does not know the initial state from which to start.
There are however some specific cases where Events may be more appropriate than State:
- Truly ephemeral events like keypresses
- Fire-and-forget requests in the Directed State pattern (see below): while theoretically unclean, it is often pragmatic to use Events here.
Example
Consider a sliding door. We model this door with an Event called doorSensorActivated. Now consider a subscribing application, Door Manipulator, that is a late joiner. The application can open or close the door when a hand is passed in front of a sensor. Depending on the state (open or closed), the door software will decide to open or close the door. Upon receiving the doorSensorActivated Event, Door Manipulator needs to know what the previous state of the door was in order to be able to take the appropriate action (i.e. closeDoor if the door was open, openDoor if the door was closed). Since it was a late joiner and does not know the initial state of the door, it cannot act accordingly.
Now consider the door modeled with a State called doorState. I has two possible values: open or closed. Consider the sensor modeled as event. When a hand is passed in front of the sensor, it triggers an event (doorSensoractivated). This event triggers Door Monitor to change the state of the door. For this, the door software listens to the value of doorState. If the value is open, it closes the door. If the value is closed, it opens the door.
For a more elaborate description of this example, go here.
Rule of Thumb for States and Events
When in doubt, use State.
