Kevin, I understand that your suggestion is another way to implement inheritance in the database. There is a great overview article at IBM that covers three different possibilities for storing objects in relational databases: http://www-106.ibm.com/developerworks/webservices/library/ws-mapping-to-rdb/
I don't like keeping different types of objects in one table because the table can become unwieldy as the number of attributes that are not shared between different child components grows. Also, one has to allow all child-specific attributes to be NULL (in case the row represents a different child object) and so the database validation that I like to do (e.g. JournalName NOT NULL) would have to be done with a trigger. Jon >>> [EMAIL PROTECTED] 12/15/03 03:47PM >>> Jon, I would usually approach this kind of thing by having one Article table with an ArticleType column that would specify what type of article and then all of the other fields you need for any type of article. So the JornalName column would only be used with an ArticleType of "Journal" or 2 or whatever, and it would be blank with the other types. This way you can keep just one set of objects. Kevin. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jon Gunnip Sent: Monday, December 15, 2003 3:17 PM To: [EMAIL PROTECTED] Subject: Re: [CFCDev] BO/DAO/Manager CFC's and Inheritance Sure, We can take an article as an example. Say that one had an ArticleBO.cfc, ArticleDAO.cfc, and ArticleManager.cfc. The ArticleBO.cfc has your properties common to all articles (e.g. Author, Length), your get/set memento methods, and your validation logic. The ArticleDAO.cfc has methods to interact with a database: Create(), Read(), Update(), Delete(). The ArticleManager.cfc is the entry point for Creating, Retreiving, Updating, and Deleting articles so it has methods similarly named. Say that in actuality, we use subclasses of ArticleBO.cfc for our application: JournalArticleBO.cfc and WebsiteArticle.cfc. These components have the same properties as ArticleBO.cfc. In addition, JournalArticleBO.cfc has a JournalName property and WebArticle.cfc has a URL property. Say that you want to do the same things to JournalArticles and WebArticles (Create, Retrieve, Update, and Delete). I'm wondering how one would model the relationships. What I am doing now is have the JournalArticleBO.cfc and WebArticleBO.cfc extend ArticleBO.cfc. When you set a memento in the child components it calls super.Validate(), for example. That is the only inheritance involved. There are 3 database tables I would design for this example. ARTICLE with ArticleID, Author, and Length columns, JOURNAL_ARTICLE with ArticleID and JournalName columns, and WEB_ARTICLE with ArticleID and URL columns. (I could have duplicated the common fields in the JOURNAL_ARTICLE and WEB_ARTICLE tables and not have had an ARTICLE table, but I thought the reuse of having the common fields in one table made more sense.) Then, I have the chilld component managers talk directly to the ArticleManager.cfc in order to Create, Retrieve, Update, and Delete the common properties that exist in ArticleBO.cfc. ArticleManager.cfc is the only component that has access to ArticleBO.cfc to update and retrieve the common ArticleBO.cfc properties from the database. Does that make sense? Jon >>> [EMAIL PROTECTED] 12/15/03 03:01PM >>> Could you give a more specific example? Its fun to theorize and I've been trying a few different ways. But it helps to have some idea of what kind of objects you're talking about. Hello all, Anyone have recommendations on how best to implement inheritance of a CFC whose functionality is split between a Business Object, Data Access Object, and Manager Object similar to Sean's article CFC in the MachII develoment guide? Would the ChildBO extend the ParentBO, the ChildDAO extend the ParentDAO, and the ChildManager extend the ParentManager? And, then once could call super.Init(), super.Load(), super.Delete() etc.... Thanks, Jon ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' in the message of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com). An archive of the CFCDev list is available at www.mail-archive.com/[EMAIL PROTECTED] ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' in the message of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com). An archive of the CFCDev list is available at www.mail-archive.com/[EMAIL PROTECTED] ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' in the message of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com). An archive of the CFCDev list is available at www.mail-archive.com/[EMAIL PROTECTED] ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' in the message of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com). An archive of the CFCDev list is available at www.mail-archive.com/[EMAIL PROTECTED] ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' in the message of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com). An archive of the CFCDev list is available at www.mail-archive.com/[EMAIL PROTECTED]
