|
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 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] |
- [CFCDEV] Help with Object Relationships Aaron Roberson
- RE: [CFCDEV] Help with Object Relationships Matthew Drayer
- RE: [CFCDEV] Help with Object Relationships Matthew Drayer
- Re: [CFCDEV] Help with Object Relationships Nando
- Re: [CFCDEV] Help with Object Relationships Aaron Roberson
