Actually this makes sense to me. I didnt realize I could pass the entire productsDAO object like that into the ProductService.
That makes total sense now. So I just invoke the productsDAO with the DSN, then pass that object when invoking the productsDAO. Then pass the productsDAO object into the variables scope in a function within ProductService. Which allows the ProductService to call ProductsDAO.getProduct() and have the query available to all the functions in ProductService. Very interesting stuff, I really need to soak this in some more so I am more confident. This is helping me understand this a lot better. Thanks for all the help. On 10/16/07, Brian Kotek <[EMAIL PROTECTED]> wrote: > > You're going down a potentially dark path there. Don't feel bad...this is > a common initial attempt to solve the problem. > > Inheritance is an "IS-A" relationship, and introduces a very special (and > tight) kind of coupling between objects. Your instinct to have your Product > CFC extend the DAO is understandable, but misguided. A Product is not a DAO. > Granted, you seem to be kind of blurring the boundary between a single > Product and multiple Products (you're calling this Products.cfc), but the > effect is the same. > > At the risk of confusing you more, I'm attaching a very simple UML diagram > that shows one way you might approach this. This is by no means complete, > nor is it an example of the "best" solution, since the best solution depends > heavily on the context of the problem. However, hopefully this might help > illustrate some of the ideas being tossed around. > > You first create a ProductDAO and pass it the DSN name (which will be > stored in the variables scope of the ProductDAO) so that it can access the > database. You then create a ProductService and pass it the ProductDAO when > you initialize it (ProductDAO will be stored in the variables scope of > ProductService). With that, things are ready to run. > > You might first want a query with all of the products in the database. > Your code calls productService.getAllProducts(). Internally, the > ProductService calls productDAO.getAllProducts(). The ProductDAO executes > a query and returns the result set to ProductService, and ProductService > returns the result set to whatever external code called it. > > You might also want to deal with just a single Product. For this, your > code might call productService.getProduct(8). Internally, the > ProductService would create a new instance of the Product CFC and set its ID > to 8. ProductService then passes that mostly empty Product CFC to > productDAO.getProduct(). The ProductDAO would run a query to get the data > for a single product, populate the Product CFC that was passed in, and > return it. Finally, ProductService returns that fully populated Product > object back to the calling code. > > While it seems like a fair bit of work up front, and there appears to be > some "pointless" forwarding around of calls, you actually gain some nice > advantages from this sort of setup. First, your database logic is isolated > away from everything else. And second, your Product object can have robust > behavior beyond simply containing database data (like calculating discounted > price on the fly based on the current user's past purchases, or figuring out > whether the Product is backordered, etc.). This is business logic, and it is > the reason why objects can do so much more than simple database query > results. > > Anyway, all this may just have made things murkier rather than more clear. > The unfortunate reality is that learning OO is very hard and you will go > through a good bit of pain and dead-ends before you feel comfortable > thinking this way. Read books, blogs, and ask questions. :-) > > Brian > > On 10/16/07, Kevin <[EMAIL PROTECTED]> wrote: > > > > OK. I think I'm beginning to digest it a bit more. > > Thanks for all the input. > > > > I still need to grasp the whole Getter's and Setter's concept. > > > > I ended up making a DAO cfc that has the query function with the query > > name in the var scope. > > > > And I call by extending my products.cfc. > > > > I am calling DAO in the super.init() method of my products.cfc like > > this. > > > > <cfcomponent extends="DAO"> > > > > <cffunction name="init" returntype="products.detail"> > > <cfargument name="dsn" type="string" required="yes" /> > > <cfargument name="item" default="" required="yes" /> > > <cfset super.init(arguments.dsn)> > > <cfset variables.instance = structNew() /> > > <cfset variables.instance.thisproduct = getdetail(arguments.item)> > > <cfreturn this> > > </cffunction> > > > > <cffunction name="getDescription" returntype="string" output="false"> > > <cfreturn variables.instance.thisproduct.DESCRIPTION /> > > </cffunction> > > > > </cfcomponent> > > > > This way all the functions have access to the query in the variables > > scope. > > Am I going in the right direction here? > > Or am I just making it harder than it is. > > > > I also need to figure out how to iterate over the query for product > > attributes (there is more that 1 row in the query) > > But I should be able to figure that out. > > > > Thanks for all the knowledgeable input. > > > > > > > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
