Background
We have a fairly complex Silverlight client which we are rewriting in HTML/Javascript/CSS, built on top of the same web services. Actually we have two Silverlight different clients which we are porting, which share some common functionality.
I read the article on http://addyosmani.com/largescalejavascript/ and am planning to use the proposed architecture, and in particular the mediator pattern.
A 10000 feet overview of the pattern described by Addy:
- code is divided into small Modules
- Modules are only aware of a mediator object; Modules cannot communicate directly with other modules
- the mediator has a simple interface for publishing and subscribing to messages
- Modules can subscribe to messages (through the mediator API), giving a callback function
- Modules can publish messages to the mediator, with a parameter object, and the mediator calls the callback method of any modules subscribed to the message, passing the parameter object
One of the main goals here is to achieve loose coupling between modules. So we can reuse the modules in the two clients. And test the modules in isolation. And the mediator should be the only global object we need, which has got to be good.
But although I like the idea, I have the feeling it is overly complicated in some cases, and that some of my team members will not be convinced. Let me explain by example:
Assume we have a helper function which performs a calculation – lets say it formats a string – and assume this function should be available to any module. This function could belong in a ‘tools’ or ‘helper’ module which is then reusable and testable.
To call this function from an arbitrary module I have to post a message, something like formatString with my input string as parameter. And the helper function has subscribed to the formatString message. But before I post the formatString message I first have to subscribe to a message like formatStringResult, with a callback function which can receive the result. And then once I get the result back, I unsubscribe from the formatStringResult message.
Question(s)
- Should the mediator rather offer this type of helper functionality directly in it’s own interface?
- Or should I extend the publish interface to allow an optional result parameter, where helper methods can directly write a result?
- Is the tradeoff of having an extra mediator layer really worth the
benefit of achieving loose coupling?
I’d really appreciate advice from developers with experience of achieving loose-coupling in ‘complex’ JavaScript applications.
You actually perfectly described the
BarFoos application Framework:https://github.com/jAndreas/BarFoos