I've played with both. Now I like to have DAO, Service and bean for related objects together in the same directory. Also allows you to do things like use "package" method access. I also tried one folder per function and had the same problems Brian is discussing.
Here were my musings on the topic back in '06 . . . http://www.pbell.com/index.cfm/2006/7/2/Directory-Structure-Redux-Protecting-with-Packages Best Wishes, Peter On Sep 30, 2009, at 10:45 AM, Brian Meloche wrote: > We used to structure as some have described - DAOs in one directory, > Beans in another, etc. I'll call that a "task" based structure, vs. > a "package" based structure, where all of the user CFCs are in one > folder, and all of the product CFCs are in another. > > We saw the opposite effect as jlcox. It was a horrible failure. When > you would, say, change something for users, you would have to bounce > back and forth from directory to directory as you're coding. > Promotions would affect multiple folders instead of one, and it was > a major PITA when you're trying to troubleshoot something. "Nope, > that isn't in the listener, it must be in the service.... oh wait, > it's in the DAO... oh hold on..." Back and forth, folder to folder. > > From my personal experience, it might sound like a good idea when > you first construct an app to group all of your DAOs together, etc. > in a task based structure, but it can fall apart later in the > project and during the rollout and maintenance phases. Functionally > in packages works much better. Since I base that on not just my > reaction, but the other developers I've worked with on various > projects, going back to the other way would not work for me going > forward. This is especially true in a large code base from my own > perspective. > > Think about it this way... task based, there is no real use for the > "package" access for CFC functions. Everything is either public or > private (unless you're in a web service/API, where you might use > remote). Grouping all of the user CFCs in a package allows you to > use the package access level and use it well, and I don't think > that's by mistake. The only functions that need to be public in the > model are your service CFCs. The rest can be package or private. The > more my brain wrapped itself around that concept, the more it made > sense to construct applications with that in mind. > > Sincerely, > > Brian Meloche > brianmeloche at gmail dot com > Producer and Host, CFConversations Podcast > http://www.cfconversations.com > Blog: http://www.brianmeloche.com/blog/ > Adobe Community Expert: > http://www.adobe.com/communities/experts/members/BrianMeloche.html > Twitter: http://twitter.com/coofuushun > User Group Manager, > Cleveland ColdFusion Users Group, > http://www.clevelandcfug.org > > > On Tue, Sep 29, 2009 at 10:17 PM, MercuryNewt > <[email protected]> wrote: > > Thank you all for your thoughts! > > I completely understand the packaging approach, but it just seems so > foreign to me for some reason. It is nice to know that I'm not > completely crazy or stuck in my old school ways. > > Thanks again! > > Tim > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to Mach-II for CFML list. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/mach-ii-for-coldfusion?hl=en SVN: http://greatbiztoolsllc.svn.cvsdude.com/mach-ii/ Wiki / Documentation / Tickets: http://greatbiztoolsllc.trac.cvsdude.com/mach-ii/ -~----------~----~----~----~------~----~------~--~---
