Futurescale, Inc. PureMVC Home

The PureMVC Framework Code at the Speed of Thought


Over 10 years of community discussion and knowledge are maintained here as a read-only archive.

New discussions should be taken up in issues on the appropriate projects at https://github.com/PureMVC

Show Posts

* | |

  Show Posts
Pages: [1]
1  Announcements and General Discussion / Architecture / Re: Application package structure on: June 21, 2007, 06:45:48
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
Pages: [1]