EventBus = good or bad idea?
David Peterson
J. B. Rainsberger
I wouldn't call it "cheating" as such, but I usually like to ask
myself, "How would I refactor towards this?" and if I don't have a
clear answer, then I probably don't understand how The Thing fits into
my design.
So can you see yourself refactoring towards an EventBus?
--
J. B. (Joe) Rainsberger :: http://www.jbrains.ca ::
http://blog.thecodewhisperer.com
Author, JUnit Recipes
Free Your Mind to Do Great Work :: http://www.freeyourmind-dogreatwork.com
Find out what others have to say about me at http://nta.gs/jbrains
Lance Walton
Lance Walton
Matt Savage
Peter Jaros
other objects in order to get around the rules?
I'd call that the Super PAC pattern.
--
Sounds: http://www.welikethisnow.com/
Words: http://www.nothingundone.net/
Conversation: (603) 548-1203
Stuart Ervine
I'm not a big fan of event buses. When I first wrote a Swing program
back in the day, they seemed to be all the rage. However you can
quickly end up with a sprawling mess, where you are never quite sure
what is connected to what. It's particularly a problem when you need
to guarantee event sequence - and can lead to many many problems.
One approach I've seen work well in a number of UI frameworks (Swing,
GWT, Lift and iOS) seems to be using a hierarchical flow. I believe
this is the essence of the PAC architecture which you've probably
heard me wittering on about in the pub. Here your UI is effectively a
tree of control and presentation (I'll collective refer to these as
Agents). Imagine you have an application that contains Groups of
people and is laid out a bit like this:
----------------------------------
Group List
Group Name, Number of Members
cooking, 1000
diy, 50
----------------------------------
Group Detail (showing people list)
Number of people over 30: 0
Name, Age
Bob, 34
Susan, 25
-------------------------------------------------
Person Detail (allowing updates of people's data)
Name: Bob
Age: 34
Update, Delete.
-------------------------------------------------
Here the hierarchy is pretty simple, and there are two low level
actions, updating and deleting. We'll assume updating or deleting
might need to call out to an external non-ui service, for example an
http service. Clearly you could use an event bus and each service and
agent could subscribe to events. However you can also just simply use
the objects to message each other.
If you construct the agent hierarchy in the following way (apologies
for the pseudo code):
groups = new HttpGroups()
people = new HttpPeople()
groupListAgent = new GroupListAgent(groups)
groupDetailAgent = new GroupDetailAgent(groupListAgent, groups)
personDetailAgent = new PersonDetailAgent(groupDetailAgent, people)
It's pretty easy to pull out an interface / trait / protocol between
the parent and the child agents. e.g. for the PersonDetail ->
GroupDetail agent
interace ParentOfPersonDetailAgent {
void personUpdated(Person person)
void personDeleted(Person person)
}
So when the user comes along an presses the update button, we want to
call out to the service, and then fire the event up the hierarchy
updateButton onPress: {
people.update(myPerson)
parent.personUpdated(myPerson)
}
The parent, in this case the GroupDetailAgent can then recalculate
it's number of people, or refresh the group details from http or
whatever.
The interesting bit to me comes when you have an event that propagates
further up the tree, and potentially down another branch of a tree. As
the original event can be translated within the agents. For example,
the user deletes a person:
deleteButton onPress: {
people.delete(myPerson)
parent.personDeleted(myPerson);
}
In the group details agent this might do something like:
void personDeleted(Person aPerson) {
myGroup.remove(aPerson);
groupDetailView.update(myGroup);
parent.groupUpdated(myGroup);
}
The group list agent could then re-request a new list of groups, or
just update locally.
The key here is the scope of the message - our GroupListAgent doesn't
really care about people being deleted, it really cares about when a
group or groups are updated.
I hope this kind of makes some sort of sense. I haven't spent a lot of
time laying this out. There's also a number of other options, for
example using the domain objects to propagate these messages, and
bind UI listeners onto them - but I've found that can lead to similar
issues as the event bus.
I'd love to hear if there are any cleaner, more concise approaches out
there, as I'm certainly no UI architecture god.
NOTE: The parent/child wiring is pretty in your face on big
applications, but I've found it to be relatively easy to navigate
using a decent IDE.
Cheers
Stuart
Matt Savage
I'm not a big fan of event buses.
David Peterson
Lance Walton
Uberto Barbini
browser is not the ideal messaging platform after all).
we started with a event listener in every object "just for the future"
and using 2-3 messages to comunicate global change of state (say user
changed language).
Later we realized the performance impact this was having and we
removed the listerner to standard event bus and we added our events
with listeners only where they were needed.
I also think this is one (rare?) case of better design pushed by
technical constraints. :)
cheers
Uberto
Jack Bolles
PS. I am moving off gmail for everything but one-way or short-term communication.
Lance Walton
Nat Pryce
I've usually used the style in distributed systems not in a single
process.
The big benefit is that you can easily change the components in the
system without fiddling with the "wiring" between them.
However, there is a trade-off. The event bus hides the dependencies
between your components. It looks like every component only has a
dependency on the bus, but really they have connections to whichever
other components produce events they must react to or react to events
that they produce. If you are not careful, the protocols between
components can become an unintelligible, fragile mess.
If you design the system right, you can back out the real dependencies
from your components subscription and advertisement definitions and
thereby visualise the real architecture of the system with graphviz or
whatever. But usually it's up to you to expose that information at
your component interfaces or even design a component system that has
interfaces which can be interrogated in this way.
The other difficulty with event buses is that it's hard to compose
components into larger components, unless you create a hierarchy of
buses. That's doable in-process but is harder in a distributed system.
So, my steer is if components must rapidly come and go, an event bus
can pay off. But if they don't, explicit wiring will be more helpful
to understand the system and keep tabs on architectural cruft creeping
in.
--Nat