>Now I can see where you might say create an order DAO that >joins the order >and products table, but what if there are certain instances >where I don't >need to know the products of an order? Should I still be >returning order >information with products if I don't need it?
You could have an order cfc with a method getOrderProducts() that you would call if and when you needed the order producs. So if you wanted to change the shipping or billing info for the order (no need for order products) you don't call it, but if you want to list the products that make up the order you do call it. >What about updating the orders >table or the order_products table where should the update >methods exist. If you want to update the order products, you could go both ways: have the order cfc be responsible for updating it's own products (in which case you jus need an order dao), or have each order product be responsible for updating itself (in which case you need an order dao and an order product dao). Here, i'd say go for option 2, because it sounds like you already consider an order product to be a different thing than an order - with it's own data and behaviour. > >Would it make sense to create an OrderDAO which the updating, >inserting, and >reading of simple order records, an orderProducts DAO which handles the >update, inserting, and reading of orderProduct records, and a >CompleteOrderDAO which is a join of the two tables for >returning complete >orders but not doing any updating or inserting? You don't need to write a "CompleteOrderDAO" since an order can load it's order products for you - but what you are describing is a gateway. Imagine you want to write a report screen that shows all kinds of info about all orders that match certain criteria (like all orders with status = backorder). You could loop through a set of these orders, load each one up, and then ask it to load it's order products, but that's not going to scale well - what you want is just a query with the data. That's where you leave the DAO's behind and use a gateway that returns a query. /t ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). CFCDev is supported by New Atlanta, makers of BlueDragon http://www.newatlanta.com/products/bluedragon/index.cfm An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
