Home → Robotlegs 1 →

Decision logic and the command map - where should the 'if' go?

• Edit

Stray

Mar 20, 2010 @ 11:06 PM

I'm interested in people's opinions about how to delegate the decision making in this scenario:

A menu has items that the user clicks to choose to load content.

Content comes in 2 flavours - with different loading requirements (type A just loads a swf, type B loads some xml, then some swfs). There are corresponding different loading requirements for each type.

The menu (and the user) don't know or care that there are 2 flavours. The menu just holds and displays data to help the user make a selection. The data for the content item chosen is always included in the custom event (or signal) dispatched when the user clicks.

Options:

1) Dispatch 2 different events, depending on the content type. Wire each to a different command that calls the correct service.

2) Only dispatch one event (that way the menu never needs to know there's a variation) - put the logic in a single command - have it look at the VO attached to the event, and decide which service to call upon.

3) Defer the logic to the service level. Have a single point of entry to a generic content loading service, and then delegate the actual work to the different loading services from there.

Where would you put the logic and why? I'm currently doing (2) because it feels like even if there was an explosion of variations, the conditional switch would at least only be in one otherwise barren place...

1. 1 Posted by odoe on Mar 21, 2010 @ 01:24 AM

   

   On my current project I came across a similar scenario, and I chose option 1. Reason being, is I look back at the service and see what I need to request. Most of the time, each service request will have it's own Command to keep it simple.

   I do have a set of services that are like requestSomethingByValue(value). In a case like this, I send all events to a single Command since the payload is the same type and let the Command decide what service function to call. It also saves me from having a dozen Commands that do practically the same thing.

   I'd rather keep the "if" in my view, because if I change how something gets called, that's usually where it will happen. I have a previous project that I still maintain where I let my Commands handle the "ifs" of events, and I'm finding updates/enhancements aren't as simple as I would like.

   • Edit

2. Support Staff 2 Posted by Shaun Smith on Mar 21, 2010 @ 03:44 PM

   

   I'd opt for 2: From the view's perspective only one thing is happening - a user is selecting a menu item. It's up to the controller, in this case a command, to translate that request into the appropriate application action. If you later decide to switch from a menu to some other form of input, or need to load the same content from elsewhere, it should be trivial to do so.

   • Edit

3. 3 Posted by Stray on Mar 21, 2010 @ 09:35 PM

   

   Thanks Shaun,

   I've stuck with (2) in the end - keeping the logic in the controller layer.

   I like the idea of the one sentence 'cocktail party' answer the class would give if you asked it what it does.

   "Hi, I'm Jim and I initiate the appropriate LessonLoaderService based on the kind of lesson the user requested." works...

   "Hi, I'm Jim and I give the user the opportunity to choose a lesson ... AND then I dispatch a different kind of event based on what they've chosen." is a definite '2 jobs' description.

   I guess you could wangle the wording around, but I think it adheres better to the Single Responsibility Principle to keep it in the Command.

   And as you say, switching the menu would be trivial compared to an implementation where the menu knows there are different kinds of lessons.

   • Edit

4. 4 Posted by odoe on Mar 22, 2010 @ 12:17 AM

   

   When you put it that way, it makes more sense :)
   I suppose I was just trying to keep the clutter out of the Command.

   • Edit

5. Stray closed this discussion on Feb 11, 2011 @ 11:35 PM.