We are now going to talk about the third variety of the event broker, and that is the situation where
the event broker is baked in and is built as part of an extension to a dependency injection framework.
In this case, I’m still using unity and I’ve built a unity event broker.
Now this is also a demonstration where I’m not going to actually implement it in live coding.
And the reason for that is that unfortunately the implementation is a bit too large.
So instead of building it as we go along, I’m going to basically talk you through how the whole thing
looks.
So let’s begin with the football player and the football coach as always.
So here is the declarative approach.
So you can see we still have an event called Player Scored.
So in this case, we want to track the player scoring goals, which is the entire point of the game.
But instead of actually calling some code for subscribing, we’re doing it declaratively by using attributes.
So I have an attribute called Publishes, which publishes a particular event on the event broker and
subsequently the football coach, which we have right here has another attribute called Subscribes to
which actually subscribes to the appropriate event.
So the assumption is that the dependency injection framework is used to construct both the coach as
well as the player.
And you’ll notice that none of the two aforementioned objects, they don’t refer to the broker at all.
So we don’t have the event broker even being injected into football player and football coach.
So the event broker itself, if we go into the event broker now, is a lot more complicated.
You can see that it’s it’s really big.
It’s like seriously big.
Now the event broker, if we just do a brief overview, it has two list dictionaries from string to
something called event sync and event source.
Now event sync and event source are mechanisms for extracting the appropriate information about what
function to call whenever an event happens.
Now we have a method called fire which actually fires the event with a particular ID and it has the
typical parameters of sender and event args, and here it simply goes through all the sinks with the
appropriate event ID and does an invoke on them.
And if it has any exceptions then it collects those as well.
So it’s a bit more thought out than just blindly calling whoever is subscribed to your event.
Now we have functions for registering sinks and registering sources.
These are not functions that you call yourself.
Remember, the whole thing is orchestrated by the inversion of control container and the dependency
injection framework.
So you don’t have to call any of this yourself.
But we basically have to register both the sinks and the sources.
Just just to explain the terminology.
Source means whoever is generating the event and sink means the event handler.
It’s just a different sets of words for expressing those ideas.
We have some utility methods like removing dead sinks and sources.
We have ways of registering and unregistering these.
And then of course, inside this very class we have definitions for the event sink and event source
and you’ll see that these are also very sophisticated because what they essentially try to do is they
try to verify, for example, that the method you’re decorating with the attribute that we’ve been using
is the correct method, that it does in fact have two arguments and that the second argument happens
to be of a type event args or an inheritor.
And it, it sort of sets the appropriate reflection properties, shall we say.
And these reflection properties are subsequently used to perform the invocation.
So this is where the actual event kind of happens.
Now if we go back to football player, you’ll see that we are still calling the event, so we’re still
calling the event manually whenever we score.
This part isn’t declarative, but what we’re not doing is we’re not explicitly wiring up this event
to be consumed by the football coach.
That’s all done in the dependency injection container.
If we look at the program itself, we will see that we are simply using the unity container as we’ve
been doing before, but we’re adding a new extension to the unity container and this is called the broker
extension.
So let’s go and see what the what the broker extension is all about.
Now, there are two things that we’re adding.
We’re adding two particular strategies to the broker.
So a strategy is just kind of like a way of telling the container that there are some additional steps
that need to be done.
And the two strategies here are called broker reflection, strategy and broker wire up strategy.
And you’ll see that here the lifetime is different.
It’s an externally controlled lifetime manager.
We won’t go into the details on lifetimes.
You would have to find a course on dependency injection frameworks to find out about all the specifics.
So just read unity documentation.
But essentially we have in the extension itself, nothing magical happens.
We just add two new strategies.
We have the broker reflection.
Strategy and we have the broker wire up strategy.
So let’s take a look at the reflection strategy.
So the reflection strategy, once again, it’s a builder strategy.
It’s a predefined interface in the dependency injection framework.
And here you specify certain things like what happens before the object is built up.
And this is where you try to register the sinks and the sources and of course to register the sinks
and to register the sources.
What happens is you sort of iterate the type so you are building up a this event event thing, you’re
building it on top of the type, and the type would be football player or football coach respectively.
And for example, since the football player is the source, what would happen is you grab the football
player, you get all the events using reflection, of course, and for each of the event info, you’re
looking for the publisher’s attribute.
And remember, we’ve defined this attribute.
In fact, publishers attribute is a very simple it just has a name and that’s it.
And it has attribute usage of event.
So the publication gets put on an event and then of course the subscribes to part gets put on a method,
but it’s also very similar.
It just has a name and there is nothing else in the attribute.
It’s in no way special.
So what we’re doing here in the broker reflection strategy is we’re actually simply finding all the
appropriate sinks and sources.
So we’re finding all the methods or all the events which are required to be wired up to something and
finding all the methods which are supposed to handle some sort of event which happens on the event broker.
And then of course, the second part of the strategy is the broker wire up strategy.
And this is very simple.
This is where you register the sinks and the sources.
And we’ve seen the register sink and register sources in the broker extension itself.
So essentially the first part is to discover those attributes that we’ve defined.
And the second part is to wire them together.
And you’ll see that instead of just doing a kind of, you know, plus equals event handling kind of
stuff, we’re actually using the event broker to keep those lists.
So remember, if we go back into the event broker, you’ll see that we have two list dictionaries here
and the broker wire up strategy is where you actually populate those two things.
And then of course, you get to fire the appropriate events.
But of course you don’t really fire the event yourself.
Instead, what happens in the football player is that you simply fire the underlying event, and the
assumption is that somewhere down the line somebody has already did, somebody already did the wire
up, so to speak.
So those two things are connected and this is done using the register sink and register source implementations
respectively.
So you add the sinks and the sources and then the rest of the infrastructure with regards to firing
up events is handled by unity itself.
So so you’re you’re kind of set in this regard.
Now, there is lots, lots more stuff going on here in terms of the the extra little parts like like
the different broker policies.
I don’t really want to go into all the details.
The source code for this will be posted next to the video.
But the point here is that when you extend a dependency injection framework, you have to do a lot more
work to get the whole thing working and it becomes a lot more.
Well, first of all, you have to realize that there is a performance cost at startup because you’re
essentially kind of every time that you are adding a new object in the container, for example, you
are effectively using reflection to find those attributes and to connect those things.
So there is a performance cost, but the end benefit and the reason why you would want to do this is
the flexibility, the fact that you can simply grab your sources and just if it source has an event,
you can decorate this event with publishes something or other.
And in fact you can duplicate these.
So we allow duplicates for both publishes and subscribes to.
So for example, you could have a method in the football coach which handles multiple situations, like
if somebody is sent off or if somebody is injured, then maybe you want to go out and and talk to them
or something.
And in this case, you can have two subscribes to with different names attached to a single method.
And the same goes for the the sources of the events, because you can here you can post several publishers
attributes to an event, and this will cause both of the both of the messages effectively to be sent
across the the actual event broker.
So this is a small demo of how you do this.
In Unity.
You can obviously do the same thing in Autofac or Ninject or any other dependency injection container.
It doesn’t really matter so long as you know what the APIs actually are.
So the benefit here is a bit a bit of.
Conciseness, a bit of reduction in the amount of code that you have to write, although keep in mind
that you still have to invoke the actual events.
Play Play Play Play Stop Play Play information alert