My girlfriend always accuses me of being contrary. Whatever the popular belief is, I am against it. If everyone loves Raymond, I hate him, everyone hates squash, I love it. etc. etc. blah blah. I don’t think I am contrary, I just think I have the unfortunate luck (or anti-luck) of holding the unpopular belief for a variety of reasons.
So goes the story in a conversation I had last night with a coworker about the Command structure in our Cairngorm project. This question was posed:
What are the responsibilities of a Cairgorm command? What is a Command’s jurisdiction? Where do the responsibilities of Helper or Manager type classes overlap a ‘Command’ type class? Are these really just different names for the same thing?
Before I go into the answers to this question, here are some reasons why this question was asked in the first place. Those reasons are as follows:
- I question everything, the why, who, what, where, and when. I never accept things ‘just because’. (am I contrary?)
- Our current code base is riddled with inconsistencies regarding MVC, Cairngorm, events, responsibilities of the MVC participants, and the list goes on. This is due to the fact that a large project has become bloated as well as our development team going from 4-5 people to over 11. ‘Too many cooks in the kitchen‘ so the saying goes.
- So with all the aforementioned inconsistencies, there is a copious amount of code duplication, views doing things that commands should probably do, models doing things commands should be doing, highly coupled custom components, etc.
The coworker with whom I had the discussion with is someone I regard as highly intelligent and somewhat experienced. But I also feel that this person, like many, takes things as is with out questioning the why, who, what, where, and when. When answering this question, he responded by saying something along these lines which you could probably find in the Cairngorm documentation:
The Cairngorm command structure was designed to serve as the entry/exit point for data coming in and out of the client and the middle-tier. Its responsibilities are to take data passed via events from the UI, direct it out of the client, wait for a response of some sort, and then update the model based on the response data (if applicable).
Wow!!! That sounds like a textbook definition of what the Cairngorm command is. So he answered part of the question as to what generally everyone would agree is the responsibilities of the Cairngorm command. I too agree but I think the command can and should do much more.
Now I hold the unpopular belief that Commands should not only handle client-mTier interaction, but that they should also handle internal client operations. Take this scenario for instance. A user clicks a city, state listing in a comboBox. That then updates some property in the model. Most folks (I believe) would just have a function inside the view go and update the model directly. From an efficiency standpoint, that’s great. But then the view has overstepped its bounds. It has bypassed the ‘chain of command’. More OOP/MVC minded people would prefer that a Manager or helper class do this where the view tells the Mgr/Helper class the update, and then the Mgr/Helper class would tell the Model. I would take this one step further and suggest that we just go ahead and have a Command do this via the whole Cairngorm event/controller/command structure You’d be correct in stating that both the onResponse and onFault will not be used and that there is possible overhead in doing so but I think you gain so much more in the long run.
There are three main reasons I suggest this:
- You maintain consistency in both the external and internal communication structure of your application so that views don’t wander out of their jurisdiction. Instead the ‘chain of command‘ is preserved.
- You maintain consistency in your code base, so that developers know exactly the who, what, where, when and how when structuring and expanding an application.
- You minimize the ‘ingredients’ for your ‘cooks in the kitchen’ to use when making new ‘recipes’.
I do acknowledge that one key to being a good developer is to be flexible and to know when to bend rules, but I also think it is key to question standards, maintain consistency, try to establish some intra-team coding standards per project and to review those coding standards every once in awhile.