With Controllers, is an event aggregator like PRISM as necessary?

May 19, 2014 at 3:20 PM
Hello all CODEr's,

In looking at the source code to the framework, I was checking out the Controllers.PopulateControllers() method. In here it examines all of the assemblies and creates a dictionary of them so that calls to Controller.Action() can locate the method in the controller specified... this is pretty much what PRISM does... a subscription to a method is logged in a dictionary and when the event is published, it is looked up and executed with whatever parms might be necessary. Frankly that is a PITA sometimes... trying to track down all of the subscribers... I modified PRISM to publish its own events so they can be tracked in a dashboard, ( http://www.codeproject.com/Articles/744302/Prism-Event-DashBoard).

But it would be easier many times to just explicitly call them using Controller.Action()... For many use cases this seems like all that is needed... Does anyone agree?

May 20, 2014 at 6:04 PM
What you get with the controller invocation the way it is right now is that once the method fires, the result is passed on to other infrastructure. So that is really the main thing that is happening there. And of course that infrastructure is pluggable and configurable. If you were to just call the controller's method, nothing would actually happen as nothing would be done with the action result.

On a side-note: We are also trying to be as similar to ASP.NET MVC's model as we possibly can, since so many people already know that.

I agree about PRISMs event aggreagator, btw. It's an abomination, IMO. I could see how event aggregation is useful in some very special cases, but the way it's used in PRISM leads to horrible code nobody can figure out. We have left an event aggregator our for that very reason.

May 20, 2014 at 7:28 PM
Hi Markus,

Yeah, the PRISM aggragator implementation I am working on is in a large internal app... and tracing down the code paths is a nightmare. When an event is published there can be 8- 10 subscribers.. and we spend an inordinate amount of time just tracking down code paths.

I definitely prefer the MVC architecture...It's something I know well from Web Connection days :) as WC followed this same pattern. Good memories!

having a controller for each V & M also keeps things much tighter.. in the PRISM framework model, there is a main module class that serves as the main "controller" for each module and it gets very unwieldy.