Event-Driven Best Practice Question

Unity Engine
1

Greetings,

So, I recently converted over to using c# events to drive interaction in my app.

Before, I used an MVC (Model-View-Controller) approach where everything was routed through the Controller which served sort of as an intermediary between all aspects of the software. So, all major parts of the software (e.g. data, user interface, web access, etc.) had references (via GetComponent) to the controller, and the controller would route requests accordingly.

However, after reading in this forum and online, I found the arguments for an event-driven approach to be convincing. So, my question is, with an event driven approach, should I still use a controller-like object that listens to all events then fires the right event for another part of the software? For example, the controller would listen for the button press event from the UI, then it would fire off a button press event that the sound management would be subscribed to and it would play a sound. Or, should the UI fire off its event and the sound management listens to that event and acts on it?

In essence, should events be routed through a controller-like object or should events simply be directly communicated to the objects that need to act on them?

Thanks.

2

Personally i would use the second way.

  1. You don´t need a second event for each event (and with that the double amount of listeners)
  2. You don´t have another dependency between the (original) sender and (original) receiver
  3. You have more code to write/maintenance
  4. You have less potential error sources

I´m not a big fan of such controller classes, at least on private or small projects. It just increases the amount of classes and code that you have and with that the error potential. There is no real benefit in my opinion.
But it´s just a personal meaning.

1 Like
3

Thanks for your reply. It helps a lot. My concern with the second way - events directly to the intended listener - is that it seems that it could get really complex on large projects with interconnecting code all over the place. However, you do have a good point in that with a controller, it seems to be adding more code since the controller is not the intended target.

1 Like
4

I totally agree with that. If it will be a large project then i would add some controllers, because then the maintenance aspect is definitely on the controller side and before you have classes with 1000 lines of code which is not (really) readable too, it should be splited. But yeah, as I said, for small/private project i wouldn´t do it.

1 Like