Technically, Coldfusion doesn't care where you put your CFC's, as long as it
can find them.
But the question is obviously how easy is it for you to find them. I guess
you either end up with a long list of folders or a long list of files, so
it's subjective as to what you prefer.
Keeping CFC's in packages makes it *slightly *easier to code by convention,
so for instance you can simply name all your DAOs dao.cfc, instead of
UserDAO.cfc, the full path/package name differentiates them. This makes it
easier to template your "objects". Of course you can also achieve this with
introspection (setDAO("#getMetadata(this).name#DAO") when you group CFCs by
function.
I think another argument in favour of CFC's in packages is that it's another
form of encapsulation, encapsulation, encapsulation. So if you want to reuse
your "object" on another app/system it is easier to copy 1 folder than find
the specific files.
Maybe the solution is to abstract the folder structure into a CF query
object, which you can sort/group by package or function and have links to
the files. The tricky part it integrating this with your IDE, I seem to
remember it was easy with ColdFusion Studio...This would make for a great
Mach-ii module, especially if it had a built in code editor and interfaced
with coldspring ;o)-
Darren
On Wed, Sep 30, 2009 at 3:45 PM, Brian Meloche <[email protected]>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/
-~----------~----~----~----~------~----~------~--~---
