Yeah I second all that Scott, cause there must be a decent way out there to separate the *pure* business logic from the database calls. I have looked at MVC and MVP and a few other methodologies, and I really dislike mixing database logic with business logic in the same CFC....I think Scott's idea of creating a parent cfc containing all get/set functions to the SQL, and then extending child cfc's off this where the logic is contained, is plausible and should work well. Time will tell of course, and until somebody comes up with a whizz bang CFC methodology I'm going with that. Another benefit of this structure is that you could extend onto it a navigation.cfc which creates your navigation hierarchy as a structure created solely from utilizing the database functions in the parent cfc, and then returning this structure to your presentation layer for use in any number of different mediums (HTML, Flash, WAP...)
Anyways like Scott said, lets see what the CFC gurus have to say on this topic. Phil "Scott Barnes" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > > Well in order for some concept slinging, I guess I should outlay my > overall objective and theories and see what pans out from here? (Why is > it when you lay out your theories / frustrations in grasping something > that maybe trivial to others..feels like you are baring your soul to the > world!) > > Objective > ~~~~~~~~~~~~~~~~~~~~~~~~~ > The key objective is to allow not only allow any given "web-friendly" > presentation layer to access my components, but also make most/some of > my methods within the components accessible to webservice calls while > making them as portable as possible. > > Application.cfm vs Containers > ~~~~~~~~~~~~~~~~~~~~~~~~~ > I have sat down briefly today and weighed the consequences of relying on > application scopes within CFC's? An example is Datasource names and DSN > username/passwords within the CFQUERY / CFSTOREDPROC tags. > > Pre-CFMX, I would typically set these variables within the application > scope, and make direct calls to these variables throughout my > application. > > In CFMX, you could continue to this, but then the CFC's would rely on > the presentation layer as its source for such variables (that or > whatever you use as your root page context layer). > > Instead of using such a method, I have thought of using a container that > is extended by all "SQL" based components. > > This then allows me to have the one cfc that can either have the DSN > details hard coded within the init() method of that component OR it > could even load the configuration from an XML packet via an argument I > pass to the container instantiation call. > > This would then take away the assumption factor but also allow for a > central configuration file for server setup. Thus enabling WebServices > to access the API calls to a component without having properties > hard-coded to individual cfcs. > > Your thoughts? Problems foreseen? > > > Business Logic that Extends to SQL Logic > ~~~~~~~~~~~~~~~~~~~~~~~~~ > I'll begin with an example of a situation where I have a "shopping cart" > app. In this shopping cart application, I have a product.cfc and a > productSQL.cfc > > The product.cfc has the extends attribute that points to productSQL.cfc, > which now allows me to access the four types of query based calls for > all product logic (select, insert, update, delete) as well as have the > ability to do non-sql based calls for the product logic all within the > one "object" (i.e. application.product.yourMethods()); > > So when I instantiate the object "products" within the application > scope, I would do this: > > application.products = createObject("component","mypath.products"); > > Which basically follows the object inheritance relationship to this: > > Products.cfc > productsSQL.cfc > AppContainer.cfc > > > Now the relationships in this concept seems to me "clucky" and untidy, > but hopefully you can see the thought process I use in modelling the > components so that they can all be housed in the one funky container. > > In doing this, I can then apply this same concept to other models, such > as "Customer" object (which would be customers.cfc > customerSQL.cfc > > AppContainer.cfc) > > My question to the CFC gurus out there is, how do you separate the > Database layer from the rest of the business logic? So that if the evil > IT Dictator walks into your cubicle and demands you halt all SQL > interactions and go forth into the dark realm of ORACLE, it in a > nutshell shouldn't be as big of a hassle as it would have in CF5.0 or > earlier. > > Furthermore, what are your inheritance/relationships between the DB > Logic and your business logic? (once again sorry for the over-use of > buzz words like "logic"). > > A Webservices Container? > ~~~~~~~~~~~~~~~~~~~~~~~~~ > In using this style of development, I then could create a > webservices.cfc which has the following as an Init() method > > <cffunction.. init()> > <cfscript> > this.products = createObject("component","myPath.products"); > this.customers = createObject("component","myPath.customers"); > this.monkeys = createObject("component","myPath.monkeys"); > </cfscript> > </cffunction> > > Its really just an empty pointer in many ways, but it will allow the > public out there to make webservice calls to the one URL > (http://www.mydomain.com/webservices.cfc?wsdl) that in return can have > access to heaps of methods via the one spot. > > Ie. > Webservices.products.getAllProducts(); > Webservices.customers.getAllCustomers(); > Webservices.monkeys.setAllMonkeysMode(spank); > > Cacth 22, is that the appContainer.cfc properties are placed inside each > component (ie 3 times) Which once again seems untidy and leaves a bad > taste in ones mouth? I could do test statements to see if the dsn > details etc already exist etc.. > > > Summary > ~~~~~~~~~~~~~~~~~~~~~~~~~ > I'm excited that CFCs opened up lots of fun ways to develop by, but like > many of the other CFC gits out there, we are left with a point of no > return in that.. what do I do, how do I do it.. wheres that firkin rule > book and where who what and when's leave me confused, wet and tired :D > > In truth I can see why patterns like FuseBox took off in the pre-CFMX > days, as it was a rulebook people could turn to and go "ahh, if I follow > this style, I'll be like all the other sheep in that following a set > path and hoping for the best" > > It's a copout I know, but I'm wanting a tight/clean way of doing > development. > > Scott Barnes > Snr Developer > eCommerce Department > Tourism Queensland / Sunlover Holidays > [EMAIL PROTECTED] > ph: (07) 3535 5066 > > --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.449 / Virus Database: 251 - Release Date: 27/01/2003 --- You are currently subscribed to cfaussie as: [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] MX Downunder AsiaPac DevCon - http://mxdu.com/
