Futurescale, Inc. PureMVC Home

The PureMVC Framework Code at the Speed of Thought


Welcome, Guest. Please login or register.
April 25, 2017, 09:01:54 PM
Home Help Search Login Register
News: ATTENTION: Spambots must die! Humans must visit http://contact.futurescale.com to request forum access.
Pages: [1]
Print
Author Topic: Application package structure  (Read 8621 times)
puremvc
Global Moderator
Hero Member
*****
Posts: 2865



View Profile WWW
« on: June 20, 2007, 07:00:26 PM »

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.

Logged
dbronk
Newbie
*
Posts: 1


View Profile
« Reply #1 on: June 21, 2007, 06:45:48 AM »

I'm a Java developer moving into the Flex arena and wanted to throw out another opinion.

What do you think about something like this:

com.myco.myapp.*
com.myco.myapp.[app domain].model.*
com.myco.myapp.[app domain].view.*
com.myco.myapp.[app domain].controller.*

Examples:
com.myco.myapp.profile.model.*
com.myco.myapp.profileview.*
com.myco.myapp.profile.controller.*

com.myco.myapp.security.model.*
com.myco.myapp.security.view.*
com.myco.myapp.security.controller.*

com.myco.myapp.common.model.*
com.myco.myapp.common.view.*
com.myco.myapp.common.controller.*

By doing this, it becomes very easy to see the classes that are involved for each section of your application.  Makes for maintenance to really be much easier.  Yes you could do:

com.myco.myapp.model.[app domain].*
com.myco.myapp.view.[app domain].*
com.myco.myapp.controller.[app domain].*

But now I'm traversing many more directories to get to the code for a single domain.

Personally, I only like to separate out the MVC layers into packages if there are going to be many classes for each application domain or I'm writing an app that is to be given to the customer(s) and allow them to extend/override.  So, in many of my apps I would use:

com.myco.myapp.security.*
com.myco.myapp.security.*
com.myco.myapp.security.*

The reason is that very often for smaller application domains I would only end up with a couple classes so rather than have a separate package with only one or two classes, I would have just the domain package with about 8 to 10 classes.  This can afford me some other very nice OO features using java.  Let's say that I follow a very common pattern used in Java web apps where I have a business class for all of my domain knowledge (say "Manager") and another class for all of my persistence (say "dao").  Because I don't want any other class calling the dao other than the appropriate Manager, I can define my dao as package scoped so that the Manager in the same package is the only one that can call it.  I know this pattern is debated all the time for web apps, but it is a proven pattern that works very well.

Ultimately, each shop needs to decide on a structure and they should follow the structure across all their projects adjusting only for special situations.  Even if they choose a structure that is not the "best", if they are very consistent in using it, maintenance costs will go down.

Dale
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2865



View Profile WWW
« Reply #2 on: June 21, 2007, 07:46:13 AM »

Dale,

You got it. Inserting your [app domain] between the app name and the MVC branches is definitely the right place in the package structure to make that break.

The original post sidestepped the whole issue of the slicing of your app into discrete functional areas. It really focused on the factors leading to the sole decision of how to make the split when you come to the tiers, ie: MVC (model, view and controller) or BMVCV (business, model, view, controller, vo).

The further question the reader was left with, (the one you answered perfectly) was:

When we slice the app into functional areas to manage the inevitable explosion of classes as an app becomes less trivial, do we make that split before the MVC (or BMVCV, or whatever) branching or after it, replicated inside each of the branches.

Clearly making that branch immediately after application name will lead to a more sensible and manageable package structure.

However if you found that you created a thousand branches at that 'com.myco.myapp.subsystem' level, it would be prudent to create some grouping for them putting them at a level one deeper like:

com.myco.myapp.subsysgroup.subsystem.model.*
com.myco.myapp.subsysgroup.subsystem.view.*
com.myco.myapp.subsysgroup.subsystem.controller.*

But the point, folks is let the major application domain related branches come *before* the pacakge structure branches made for the sake of MVC framework affinity.

Thanks for bringing this up, Dale. It adds a valuable dimension to the thread.
Logged
Pages: [1]
Print
Jump to: