Nando, Thank you for that very helpful reply. I think this may be another case of over complicating things.
-Aaron On 12/20/06, Nando <[EMAIL PROTECTED]> wrote:
Aaron, Hang on! Don't hit the wall on this one. The simple answer is that you often *don't need* to create the at-first-glance apparent object relationships in your OO model. For me, i've found that you only need those relationships when objects need to work together to DO something in your app. Think more toward working teams when designing your object model, teams that work together to accomplish a *specific* task. Forget about the conceptual groupings. If Article and Product don't do something together *at the same time*, they probably don't need to be related. My quick hit on your specific case here is that Products and Articles are only conceptually linked for the user of your app. To do that, you need a linking table, that's true. But in the actual flow of what the application does, if products and articles are edited in separate screens for instance, then you'll be fine just with a gateway method that uses the appropriate SQL join as your only linkup between them in your model for the display portion. That can be in your ProductGateway or your ArticleGateway or you can have different variations in both. In your editing form for products, you can instantiate a Product and use an ArticleGateway method to get the list of articles for your dropdown. Your Product DAO handles the SQL for the Product and your linkup table. Something like that. Now, if you have a form that you enter the article information and the author information at the* same time*, and an article can have multiple authors, then you're in the territory where you need to think about composition *to accomplish this specific task* ... but it will be pretty clear to you how to manage that when you get to the code. You might instantiate an array of Authors in your Article bean and pass that to a ArticleDAO that was structured in exactly the same way, with an array of AuthorDAO's composed within it. It works well. Sounds more complicated than it actually is. If you add authors first and then add the article in a second step choosing from a dropdown list of authors, or if you only have room for one author per article, then you probably don't need to compose those objects together to get the task done. Does that help? Don't let the OO books screw your head up here. Speaking from experience here! A lot of the beginner examples composing engines, tires and windshield wipers in a car and then aggregated in a parking lot are misleading because they can give you the impression that that's how you build your applications. It ain't true, unless you want to drive yourself nuts. Yes, you *can* build some very complex models and get your application to work that way, but it's unnecessary and probably a big waste of your time and server resources. Keep it as simple as possible. I'd suggest that you compose your business objects or beans only when they need to work together in a particular moment to get something done. I hope that helps ... Nando I am converting my spaghetti code application into OOP and have separated everything out to beans, gateways, DAOs and services. I am running into a wall trying to figure out how to establish relationships between objects. For example, I have the following tables in my database that have one-to-many and many-to-many relationships: PRODUCTS (table) prodid (pk) title description price ARTICLES (table) articleid (pk) authorid (fk) title content PROD_ART (linking table) prodid (fk) articleid (fk) AUTHORS (table) authorid (pk) firstname lastname bio How would I define these relationships? Each author has several articles, each article is related to many products and each product is related to many articles. I have installed and created a blog using Model-Glue Unity to see how Reactor defines these relationships but I cannot translate that over to my application. Do I create these relationships in the service layer, gateway, bean, etc? Thanks for your help, Aaron Roberson You are subscribed to cfcdev. To unsubscribe, please follow the instructions at http://www.cfczone.org/listserv.cfm CFCDev is supported by: Katapult Media, Inc. We are cool code geeks looking for fun projects to rock! www.katapultmedia.com An archive of the CFCDev list is available at www.mail-archive.com/[email protected] -- <http://aria-media.com/> Aria Media Sagl CP 234 6934 Bioggio Switzerland www.aria-media.com <http://aria-media.com/> You are subscribed to cfcdev. To unsubscribe, please follow the instructions at http://www.cfczone.org/listserv.cfm CFCDev is supported by: Katapult Media, Inc. We are cool code geeks looking for fun projects to rock! www.katapultmedia.com An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
You are subscribed to cfcdev. To unsubscribe, please follow the instructions at http://www.cfczone.org/listserv.cfm CFCDev is supported by: Katapult Media, Inc. We are cool code geeks looking for fun projects to rock! www.katapultmedia.com An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
