Glad it helped and didn't hurt. ;-) To be clear, you only pass the DSN to the ProductDAO once, and you only pass the ProductDAO to the ProductService once. You would do this at application startup, and then store the final, fully-configured ProductService in the application scope. In this way, it is available to all requests over the entire lifetime of the application. So really, the rest of your app would be calling application.productService.getProduct(266) or something similar.
So the challenge rapidly becomes managing the creation and dependencies of your CFCs. At the risk of stretching your brain even more, I wrote an article on my blog about this problem and how the ColdSpring framework helps solve it. While I don't think you probably want to run ahead and tackle ColdSpring as well, looking at the blog entry might plant a helpful seed and give you a preview of where you might be going with this once your model becomes sufficiently complex. The article is at: http://www.briankotek.com/blog/index.cfm/2006/5/31/Why-Use-ColdSpring. Please note that while the entry also happens to revolve around "products", don't read too much into it or assume that the way I'm showing things in that article is the "proper" way to do things. It's just for illustrative purposes. As I said before, the actual arrangement of objects that you need depends on the specific context. We've had something of a joke going in the CF world nowadays that Sean dubbed the "5 to 1 syndrome" where every table in the database ends up with five CFCs to represent it in the model. On 10/17/07, Kevin <[EMAIL PROTECTED]> wrote: > > 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 -~----------~----~----~----~------~----~------~--~---
