tag:robotlegs.tenderapp.com,2009-10-18:/discussions/questions/113-best-practice-for-reusing-a-generic-servicecommand-and-notifying-the-appropriate-modelRobotlegs: Discussion 2018-10-18T16:35:10Ztag:robotlegs.tenderapp.com,2009-10-18:Comment/13288302010-03-31T14:37:06Z2010-03-31T14:37:06ZBest Practice for reusing a generic Service/Command and notifying the appropriate Model?<div><p>I'm not sure that I entirely follow your example, but I
definitely wouldn't pass the model along via the event. Perhaps
another approach is:</p>
<p>A single Service, AnimalService, with method
findAnimalsForState(state:string).</p>
<p>You might call that directly from a mediator, for example, or
from a command.</p>
<p>Once the service has retrieved the result it fires off an event
(including the type and the results).</p>
<p>A command is bound to this event that looks at the type and set
data on the appropriate models.</p>
<p>When data changes on a particular model it too fires off an
event that a mediator interested in that model might respond
to.</p></div>Shaun Smithtag:robotlegs.tenderapp.com,2009-10-18:Comment/13288302010-03-31T18:06:31Z2010-03-31T18:06:31ZBest Practice for reusing a generic Service/Command and notifying the appropriate Model?<div><p>[Shaun: <em>Once the service has retrieved the result it fires
off an event (including the type and the results). A command is
bound to this event that looks at the type and set data on the
appropriate models.</em>]</p>
<p>What I was trying to avoid though was that "look at the type"
logic. I'll end up needing some ugly if/switch logic somewhere (eg
a Command), that has to do...</p>
<p>if (type == "mammals") { //notify Mammals model or dispatch
event to notify a Mammals mediator<br>
else if type == "reptiles")<br>
...</p>
<p>So the reason I passed the Model in directly through to the
Service layer is to leverage polymorphism and avoid having to deal
with the "if" logic somewhere.</p>
<p>I'd think the concept of reusing a generic type of service for
things must come up quite frequently so that's why I'm curious how
its handled. For example you might have a generic "Sports Teams"
service that returns teams for a type of Sport... but when the
service returns you only want the appropriate view or model for the
Sport responding to it. For example, you might be on a unique
"Hockey" view and it needs a list of "hockey" teams. I don't want a
"Football" model, mediator, or view notified when I'm using the
generic "sports teams" service to return hockey teams.<br></p></div>rickcrtag:robotlegs.tenderapp.com,2009-10-18:Comment/13288302010-03-31T21:18:04Z2010-03-31T21:18:04ZBest Practice for reusing a generic Service/Command and notifying the appropriate Model?<div><p>well.. i don't think there is any magical solution: if you use a
generic service you either have to:<br>
- try to find what model might be interested in the result and
update it (see Shaun answer)<br>
- send a generic event on return and have all models check if they
have any interest in the result (each individually) (in HockeyModel
update method: if result != HockeyRelated return;<br>
(note that in both solutions only the models are affected -no view,
mediator, etc.- and once the model(s) is updated it sends an event
to inform the other actors (mediators, etc)</p>
<p>both solution seem better than carrying a model reference
everywhere (imho of course)</p></div>sitronniertag:robotlegs.tenderapp.com,2009-10-18:Comment/13288302010-03-31T21:51:35Z2010-03-31T21:51:35ZBest Practice for reusing a generic Service/Command and notifying the appropriate Model?<div><p>Ok thanks sitronnier and Shaun. I actually was leaning towards
approach two above in your example sitronnier, even though it did
seem to add extra chatter- models being triggered with an event
they are only 'sometimes' interested in.</p>
<p>That has me wondering...</p>
<p>1) I'm assuming it's bad practice to pass a "callback" into your
event which would eventually be handled later on - possibly in the
service result (passed as a token). Whatever initiated the event to
fire the generic service could pass in a callback that it cares
about firing when the final service event returns .. and you just
call "execute(someData)" (or whatever your defined interface is for
the callback.) I guess this is an anti-pattern since your supposed
to be dispatching and listening for events.</p>
<p>2) Just curious on the drawbacks to passing the model that
implements an interface into the event as I was doing? In reference
to the Sports theme - your HockeyModel might implement
ICanBeSetWithTeams interface which requires a "setTeams(teams)"
implementation on your model. Overall it seems to keep the code
clean, but It does seem a bit ugly in the sense that I have to
attach it as an asynch token for my service response to execute
on.<br></p>
<p>I'll probably change things to either of your approaches since
you guys are the masters (and something will probably come back to
bite me using my interface approach), I'm just curious so I could
learn good design habits within RobotLegs.<br></p></div>rickcrtag:robotlegs.tenderapp.com,2009-10-18:Comment/13288302010-03-31T23:40:28Z2010-03-31T23:40:28ZBest Practice for reusing a generic Service/Command and notifying the appropriate Model?<div><p>I think it depends on what your view component is supposed to be
presenting: does it represent the application's state (the model),
or some arbitrary external resource? If it represents a simple
list, and no other part of the application cares when such a list
is loaded, and loading that list won't change the application's
state in any way, then sure, use a callback (or a Promise). I do
that quite often.</p></div>Shaun Smithtag:robotlegs.tenderapp.com,2009-10-18:Comment/13288302010-04-01T00:08:49Z2010-04-01T00:08:49ZBest Practice for reusing a generic Service/Command and notifying the appropriate Model?<div><p><em>[Shaun]: If it represents a simple list, and no other part
of the application cares when such a list is loaded, and loading
that list won't change the application's state in any way, then
sure, use a callback (or a Promise). [/Shaun]</em></p>
<p>That's <strong>Exactly</strong> what it is:, a simple list (used
to populate some tree controls) that happen to be composed of
different items based on the 'id' of the kind of view I'm dealing
with. (The service is generic and can by used by different
mediators.)</p>
<p>Excellent to know that using a callback in this case is ok.
(I'll have to research "Promises" - haven't used them (at least
maybe using that term?) Thanks again.</p></div>rickcr