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

Pages: [1]
Print
Author Topic: Real world PureMVC folder structure  (Read 13105 times)
Sammi
Courseware Beta
Full Member
***
Posts: 45


View Profile Email
« on: July 20, 2009, 06:20:07 »

Hi,

I always feel a bit lost on new projects when it comes to folder structure in a PureMVC application.  I really like the suggested structure:

\model
   \vo
\view
   \components
\controller

But that soon gets really messy in larger projects.  I find that my view and components folder get expecially messy.  That is why I always try to come up with a good folder structure within thos folders - and that is where I fail.

Either I get too granular or too general.  Often I end up with inconsistency and bad naming conventions inside the components folder.  I try to suffix 'real' views with View and other classes that the views use not.  But in the end there are so many classes that are not real views that the components folder get messy.  Then I sometimes move those classes outside of the components folder into some other folder but am never sure what folder name I could use that makes sense.

So I was hoping some of the more experienced PureMVC developers could share some of their experience in this area?

How does the folder structure look like in your real world application?  What structure do you use to keep everything clean and logical?

Best,
Sammi
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #1 on: July 21, 2009, 07:27:58 »

You can always subdivide your components folder by section of the app or whatever. But if its really getting so out of hand, then it's quite likely you should move to MultiCore. This will give you another level of granularity to things. Here's the suggested package structure for MultiCore apps: http://forums.puremvc.org/index.php?topic=1308.msg6048#msg6048

-=Cliff>
Logged
JJfutbol
Sr. Member
****
Posts: 53


View Profile WWW Email
« Reply #2 on: July 27, 2009, 10:12:32 »

Sammi, I agree. I found that out very quickly that I really didn't like that setup. It creates way to much hierarchy and sometimes doesn't give the organization I want. Since I use PureMVC with Flex/AIR projects I've been following (and others where I work at) the Flex framework way of organizing components. I define a "model", "view", and "controller" folder and the only contents of those folders are the respective PureMVC actors: Proxy, Mediator and Command. So when it comes to views I use packages like: "controls", "containers", "utils" for utilities, etc. I've found this setup much more productive and offers me more organization without the deeply nested folder hierarchy.
Logged
Sammi
Courseware Beta
Full Member
***
Posts: 45


View Profile Email
« Reply #3 on: July 27, 2009, 12:48:17 »

That actually sounds like a good idea.  I wonder what "view/components" followers say about that.

Cliff suggests that this organization occurs inside the components folder like this:

view
   \components
      \controls
      \containers
      \utils
      \...and so on

But I think I am like you JJ and dislike too much hierarchy. But what would be the arguments against moving the view classes out of the components folder? 
 

Best,
Sammi
Logged
JJfutbol
Sr. Member
****
Posts: 53


View Profile WWW Email
« Reply #4 on: July 27, 2009, 12:54:52 »

The argument for me would be is if you really want anything organized by a root model, view, and controller directory. Personally, I don't see the value in that. I've tried it and found it to be much more work but then I work pretty much 100% with Flex so I'm very used to how they do things and have applied their packaging practice. I think this is most valuable for my projects since knowing Flex is a requirement and by knowing it anyone should feel just comfortable with the structure. My argument for how I do packaging is each package has its own unique set of classes. PureMVC defines its own classes for the view, model and controller so I'll have those classes there. For example, my projects would be like:

  • com
    • arc90
      • myApp
        • controller (contains only Commands)
        • model (contains only Proxies)
        • view (contains only Mediators)
        • enum
        • delegates
        • utils
        • containers
        • controls
        • core

I've found it much more maintainable this way when I have one package I open I just see those specific files, rather than that and 20 or 30 others.
« Last Edit: July 27, 2009, 12:58:58 by JJfutbol » Logged
Sammi
Courseware Beta
Full Member
***
Posts: 45


View Profile Email
« Reply #5 on: July 27, 2009, 01:21:07 »

Roger that.

I like this way of organizing things.

Best,
Sammi
Logged
JJfutbol
Sr. Member
****
Posts: 53


View Profile WWW Email
« Reply #6 on: July 27, 2009, 01:30:51 »

I think so too especially if you are working fully in Flex. The best practice that Cliff has outlined is great if you are really working across various projects in various languages and honestly just want to follow the best practice. Since I work with the Flex framework (and dig through the source very often!) I'm used to the way they do packages so I prefer that. Whatever works for you, use it well!
Logged
Jason MacDonald
Sr. Member
****
Posts: 243


View Profile Email
« Reply #7 on: July 27, 2009, 04:19:16 »

The only things I put under the view/components are components that are directly related to the mediators and not likely to ever be reused (because they were created for a very specific purpose). I use a completely seperate hierarchyfor my reusable components like containers and controls, similar to the Flex framework hierarchy. Only my PMVC app files go under the traditional model/view/controller folders.

« Last Edit: July 28, 2009, 05:56:24 by Jason MacDonald » Logged
Sammi
Courseware Beta
Full Member
***
Posts: 45


View Profile Email
« Reply #8 on: July 28, 2009, 02:03:15 »

Yes, I was thinking about that too.  It makes sense to keep reusable view components out of the project specific package structure, just like any third party reusable classes.

Best,
Sammi
Logged
Pages: [1]
Print