tag:robotlegs.tenderapp.com,2009-10-18:/discussions/problems/466-no-subjectRobotlegs: Discussion 2018-10-18T16:35:36Ztag:robotlegs.tenderapp.com,2009-10-18:Comment/130649442012-01-21T05:17:47Z2012-01-21T05:17:48ZNo subject<div><p>After thinking a bit more, am I just over-engineering? I could
just access the service directly from the mediator.</p></div>Stutag:robotlegs.tenderapp.com,2009-10-18:Comment/130649442012-01-21T11:11:49Z2012-01-21T11:17:39ZNo subject<div><p>The disadvantage of accessing the service directly from the
mediator is that if you decide you need to use a model which is
updated by the service and want to access those values in your
mediators instead you'll be rewriting your mediators.</p>
<p>Finding the right level of abstraction is always a bit of an
exercise and it depends on a few factors:</p>
<ul>
<li>
<p>Are the views conceptually tightly coupled to the service? For
instance a view could be a visualisation of an async process, in
that case it makes sense to let the view's mediator access the
service directly (still using an interface obviously, in order to
be able to swap the service implementation)</p>
</li>
<li>
<p>the scope of the application and the possible reuse of its
various elements in the future. Can you imagine you'll be reusing
the views and their mediators in a derivative of the current
project? Or wholly new projects? If yes, then it makes sense to up
the level of abstraction, if not you can get away with a tighter
coupling.</p>
</li>
<li>
<p>will the view need more data than what the service provides? If
it needs (or WILL be needing) data from a few models, services etc.
it makes sense to have a request-response mechanism especially if
it needs all of that data at approximately the same time (for
instance on registration) since it will have fewer dependencies and
therefore is more easily maintained if a command is doing the data
collection work.</p>
</li>
<li>
<p>Is a polling mechanism necessary? Could the mediator be
responding to messaging with the necessary data as a payload
instead? For instance it could listen to the a MicrophoneMuteToggle
signal that carries a MicrophoneMuteToggleVO instance with an
isMuted property.</p>
</li>
</ul>
<p>It's always a balancing exercise between not painting yourself
into a corner and not doing too much unnecessary abstracting.</p></div>creynderstag:robotlegs.tenderapp.com,2009-10-18:Comment/130649442012-01-25T04:47:38Z2012-01-25T04:47:39ZNo subject<div><p>Thanks for your comprehensive response. I've decided to go for a
payload system with the signal, and the mediators are using
promises to asynchronously communicate with the microphone.</p></div>Stu