I've used the "directory per substantive model concern" method in the past
and find that it gives good flexibility. That way you can keep all of your
related CFCs together.
Some have gone the route of mapping CFC folders to follow the Java
convention of using domain names for packages.
So, given that my domain name is chrispetersweb.com, if I wrote my own blog
app, I would package the CFCs like so:
com/chrispetersweb/blog/,
which would get called like this:
<cfset blogService = CreateObject('component',
'com.chrispetersweb.blog.Service')>
(or whatever) I've downloaded a few apps recently that took this approach.
What does everyone think of that? Are the cool kids doing it differently
these days? :)
On Wed, Dec 3, 2008 at 7:07 AM, Peter Bell <[EMAIL PROTECTED]> wrote:
>
> The key benefits of putting all the stuff to do with a given business
> object in one directory are (a) it's easy to see all the stuff related
> to that object and (b) you can use "protected" to limit access to (for
> instance) DAO methods to other components in the same directory (such
> as the related service or business objects).
>
> I would personally use the term package for groupings of business
> objects though. You might have a commerce package with product,
> category and attribute object directories - each containing the
> associated DAO, service class, business object, etc.
>
> One downside of the "directory per business object" approach is that
> it will move you towards 5:1 coding where you have a service class,
> DAO, maybe gateway, business object and possibly even a controller for
> every business object which isn't ideal if you're hand writing your
> applications and leaves you in a strange place if you ever start to
> use value objects which may simply be used for transiently adding
> behaviour to subsets of an objects data (you might use an Address VO
> for address fields within an Order (assuming a schema where you store
> bill and ship address in the order table) even though all of the
> persistence concerns would be handled by the Order object.
>
> I actually just use one directory for ALL of my model CFC's, but that
> is because about 98% of my "objects" are described in XML and don't
> have physical CFC's so it works for my use case. You could try one
> directory per business object, but perhaps one directory per
> substantive model concern (commerce, etc) might give more flexibility.
>
> Best Wishes,
> Peter
>
>
>
>
> On Dec 3, 2008, at 6:44 AM, aliaspooryorik wrote:
>
> >
> > Hi,
> >
> > Just curious what directory structure people use to organise their
> > CFCs. It makes sense to me to organise classes into packages. For
> > instance business object, service method and DAO for each domain
> > object into their own directory (product, order), and all Utils in
> > another folder.
> >
> > This approach works but I just wanted to know if there is a better way
> > - to which the answer is probably "it depends" :)
> >
> >
> > >
>
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"CFCDev" group.
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/cfcdev?hl=en
-~----------~----~----~----~------~----~------~--~---
