This anti-pattern is probably more applicable to large MVVM based applications, and it might even just be a pet dislike of mine. I better clarify what I mean, this pattern is known by different terms, it's also known as Event Broker (PRISM). It shouldn't be confused with an enterprise message bus, what I'm talking about is a UI layer applicable pattern, which is used to communicate internally by the UI implementation. The UI might well still use an enterprise message bus to communicate with disparate backend systems.
Shown below is a really simple interface & implementation of a message bus, this service would normally be a singleton instance shared between all view models & other services:
Conceptually as you can see all it does is connect a publisher to a consumer on a particular topic. Now this a very powerful concept and when used well. It provides a clean way to communicate between disparate view models & services in the UI.
For me the ability to communicate this way, cross-cutting any structure you have for the view models, services & controllers seems wrong - when you've gone to the effort to separate out the classes and logically grouped them this all seems to be undone by using a message bus.
In larger MVVM applications you're more likely to have a controller sitting behind your main view model to orchestrate service communication and interaction between view models & services, and this is probably why I see this as an anti-pattern because it can destroy this structure. It almost could be considered another way to do the Service Locator pattern.
Another downside (just as important IMO) comes when you're debugging or re-factoring a code base - how difficult can it be to find where a message came from or which subscriber is causing an issue, especially when the call stack has been lost because the subscriber is handling the message on another thread.
Shown below is a really simple interface & implementation of a message bus, this service would normally be a singleton instance shared between all view models & other services:
For me the ability to communicate this way, cross-cutting any structure you have for the view models, services & controllers seems wrong - when you've gone to the effort to separate out the classes and logically grouped them this all seems to be undone by using a message bus.
In larger MVVM applications you're more likely to have a controller sitting behind your main view model to orchestrate service communication and interaction between view models & services, and this is probably why I see this as an anti-pattern because it can destroy this structure. It almost could be considered another way to do the Service Locator pattern.
Another downside (just as important IMO) comes when you're debugging or re-factoring a code base - how difficult can it be to find where a message came from or which subscriber is causing an issue, especially when the call stack has been lost because the subscriber is handling the message on another thread.
Comments
Post a Comment