Thanks Brain. So essentially you're saying, C can have a reference to A directly, even though C also has B that has A?
'cause right now... C -> B -> A C -> A So as long as there's not cyclic object references, it is fine, right? And yes, you've proven to me why I feel like Transfer is in the way sometimes. Thanks, Henry Ho On Feb 18, 5:51 pm, Brian Kotek <[email protected]> wrote: > Ideally the database structure should have no bearing on the object model. > In many cases the two may be similar, but there are plenty of situations > where they aren't. My advice would be not to couple them unless you have a > good reason. Transfer creates objects that are fairly tied to the database > schema, so for many the tradeoff of having Transfer do a lot of work for you > is worth the coupling. Though you can get around some of that by using it's > Decorators. > > One of the nice things about Hibernate is that it allows a lot of > flexibility in designing the object model because in most cases it can just > generate whatever database schema is needed to support the model. > Essentially, you just say "persist this" and you don't care how Hibernate > does it. > > If you're looking to get something done quickly and want to use Transfer or > one of the other CF ORMs, then fine, but at the least I would say create > your model first, and then figure out what you need in terms of a schema to > allow that to work in Transfer or in your own DAOs and factories. But if > your goal is to learn more about OO design, I would stop thinking about the > database right now. > > On Wed, Feb 18, 2009 at 8:29 PM, Henry <[email protected]> wrote: > > > I'm not sure if this is a good question. Please forgive me if this is > > one of the 'it depends' question without a use case. > > > Imagine these relationships: 1 A has many B, and 1 B has many C... > > > In reverse: C has 1 B, and B has 1A. By transitivity, C has 1 A. > > > in DB, we have: > > > TableA > > a_id > > > TableB > > b_id > > a_id (fk to TableA) > > > TableC > > c_id > > b_id (fk to TableB) > > > If a method in object C needs something from A to carry out the > > operations... > > > solution 1.) the most obvious, but quite procedural way of doing OO: > > > > getB().getA().someMethod() > > > It works, but it doesn't smell right. Some would say this is not OO, > > but procedural programming with CFCs. Correct? > > > solution 2.) let C have a reference to A, assigned by a setter or at > > Init() > > > > variables.a.someMethod() > > > It works, but... C does not really have a reference to A in the DB, so > > the DAO will be very different from DB, or is it considered okay? > > > solution 3.) Maybe the problem is wrong? move the method into A, and > > pass C in as argument > > > <cfcomponent name="a"> > > function someMethod(C c) { > > > // do things in A > > > c.doSomething(); > > } > > </cfcomponent> > > > Thanks, > > Henry Ho --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
