Yeah - I keep trying to come up with a business justification for sharing/open sourcing it, but right now the math still doesn't add up.
That said, I've shown it to a few people one-on-one, I show pieces when I do my RAD OO preso, I'd be open to sitting down one on one at a conference in the bar if anyone wanted a look, and I could even do a preso at cf.o() focused on how it all really works together and in practice - maybe I'll submit that as a topic and see if there is any interest or not. Best Wishes, Peter On Dec 3, 2008, at 11:24 AM, Brian Kotek wrote: > Since it's the basis for his business, it's probably unlikely that > he'll give it away. ;-) > > That said, SOMEDAY I want to see it too! > > On Wed, Dec 3, 2008 at 7:12 AM, Alan Livie <[EMAIL PROTECTED]> > wrote: > I'd love to see this homemade framework of yours Peter (pardon the > innuendo!) :-) > > From: Peter Bell <[EMAIL PROTECTED]> > To: [email protected] > Sent: Wednesday, December 3, 2008 12:07:57 PM > Subject: [CFCDEV] Re: CFC Directory structure > > > 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 -~----------~----~----~----~------~----~------~--~---
