Ok - sorry. Complete mis-understanding on my part. Not enough sleep this week.
Good to know that TogetherSoft's tool doesn't change the code - I'll check it out. Thanks for that. When I said a hundred methods - I meant over all cfc's in an app. Not in a single cfc - that would be crazy. But I still have trouble remembering method names when "gluing" them together to form the main processing of the app. I think that I now understand what you mean about wrapping the database with cfc's. We're currently in the process of redesigning our main product and are considering such an architecture. However, while disassociating the display from the business logic is easy, disentangling the database access from the business logic is much harder. It's such a radical change that we may rewrite with that in mind and then factor the database access out afterwards. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Sean A Corfield Sent: Wednesday, 6 August 2003 15:04 To: [EMAIL PROTECTED] Subject: Re: [CFCDev] IDE's On Tuesday, Aug 5, 2003, at 21:38 US/Pacific, Rod Buchan wrote: > Thanks for the tip about the UML CASE tool, but I'm highly suspicious > of > code generators (unless I wrote the code generator). TogetherSoft's tool is not really a code generator in the 'old' sense - it can take your existing Java code and generate a visual representation (model) which you can manipulate and it keeps the code and the model in sync. I've used it for years and it's never mucked with my code. > CFC's don't need to be super complicated before you can easily have a > hundred or so methods. That's too many to keep in my brain at once. A hundred methods? You're kidding right? In the whole of macromedia.com - some quarter of a million lines of CFML - no CFC has anything close to a hundred methods!! > I'm surprised that you wrap single database tables by single cfc's. > There's > a huge mis-match between relational data and object orientated data. You're thinking of this the wrong way: I'm not talking about creating objects that are 1:1 mappings of relational tables. That is doomed to failure and will create a very inefficient and non-scalable system. Having a CFC act as the interface to a table is not the same thing - it's just a proxy to encapsulate the SQL, not a row-based mapping of objects. Sean A Corfield -- http://www.corfield.org/blog/ "If you're not annoying somebody, you're not really alive." -- Margaret Atwood ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [EMAIL PROTECTED] with the word 'unsubscribe cfcdev' in the message of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com). ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [EMAIL PROTECTED] with the word 'unsubscribe cfcdev' in the message of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com).
