|
This is a brief post regarding recommended package structure for PureMVC-based applications.
First, if you look at the pacakage structure of the CodePeek application, you see:
com.futurescale.codepeek.*
com.futurescale.codepeek.model.*
com.futurescale.codepeek.view.*
com.futurescale.codepeek.controller.*
If you have a look at the package structure in the CafeTownsend demo, you see:
com.gurufaction.codepeek.*
com.futurescale.codepeek.business.*
com.futurescale.codepeek.controller.*
com.futurescale.codepeek.model.*
com.futurescale.codepeek.view.*
com.futurescale.codepeek.vo.*
The CafeTownsend demo was ported by Michael Ramirez and he did so with an eye toward Cairngorm developers and architects evaluating or migrating to PureMVC. So its package structure is influenced by Cairngorm. ARP has a similar format.
One thing I don't like so much about either package structure is that it makes you 'think' every time you look at it. It has crossed some visual threshold were we have to consider the 5 or so options, and consider what we're looking for and arrive at the conclusion as to which folder to open.
True, vo's may be shuttled around the three tiers and therefore logically stand 'outside' it also adds an extra package branch. The business delegate may do work for the controller or the model, and therefore would logically stand on its own island as well.
The reason I use the more simplistic 'model, view and controller', is that the original intent was to help separate code into three discrete 'piles'. This overcomes 90% of the problems we have with muddy responsibility placement in our apps. You still stand at the same crossroads, it only takes less time to pick a path.
So like everything, it's a compromise. More logical separations, which is good if there is an explosive number of classes that could be subdivided, or more minimal packaging, which is faster to traverse and means fewer regular occurrences of staring at your package structure wondering where something is, if only for seconds longer at a time.
|
Show Posts
