I have to agree here with scott on MVC on his description of a controller in MVC. Your model is acutally your business logic and your persistence. The fact that you have separated the model into 2 layers just means you are looking at the model at one layer of abstraction lower.
Regarding you other issue of where to get Application variables from, I propose this soloution: 1. Use an XML config file. (but you could also use a db since its up to you how you get the struct you return) 2. for each application, have a 'configuation' cfc that loads the xml file and has a method 'getAppVars' that loads from the xml file/db. this returns a struct. 3. in each cfc you create have a config property and a setConfig( Struct s) method. (which you could overcome this overhead by making a generic class with this method that everything inherits from). Then, when you need to reference an app var from inside a cfc you just need to call 'this.config.dsn' Obviously you have to overhead of setting this each time you instansiate your components. (You could overcome this with a Factory Component that did it for you) 4. To save reading the config struct each time from your configuration.cfc you can do this once in you application.cfm and store it in application scope. 5. From my understanding you would be building a webservices component that acts as a 'facade' to all your other logic. So your problem here is that you need to reference your components without having the facility of an application.cfm. In this case you just need to manually load your struct from the configuration.cfc by calling getAppVars. With regards to having the persistence methods in the inheritence heirarchy, I agree with Gary's point about 'is a' and 'has a' relationships. With my idea above you could still do what your saying about changing the XML file from SQL to mySQL and have the database storage change AND not have to inherit your db objects. It would work like this: inside you init() method of each component you would have. this.dbManager = this.getmetadata().name & 'DbManager' & this.config.dbtype e.g. dbManager would be either productsDbManagerSQL.cfc, productsDbManagerMySQL.cfc or productsDbManagerOracle.cfc Thats just some of my ideas. feel free to steal, copy, pull-to-pieces or disregard accordingly. Pat Branley "Scott Barnes" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] "gary menzel" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] I just want to make some comments on a few little slabs of Scott's original post and then some general observations we have tested out here since the post arrived...... > 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). I was a little bit confused by the comment that the Application space is some how part of the "presentation layer". It is not really part of any layer at all - but is just a place to store stuff that all parts of the application can get at. What i meant is, that we keep our Components outside of the applications initial root directory and store them elsewhere, if you have an application.cfm that sets everything from dsn values to file mappings, this does rely on your applications "presentation" layer, in that the HTML/FlashMX side of things push that information into your CFC's and in your CFC you would then assume #application.blah# exists. But.. If you where to use parts of your CFC, it being outside the applications root directory can't access these variables as the server is in a different area, thus the CFC's can't understand why application.blah isn't available. So in a way, using the MVC methodology, the application.cfm sort of becomes the controller, and the controller and view being more towards the presentation layer side of the fence it becomes apart of it. The controller in my view acts like the Index.cfm?FuseAction in FusebOX, in that it awaits for an event to be triggered, interprets that event and decides where to push the data to (ie which methods within the model to execute), the model then processes/data manipulation of the data pushed, and either ends its call to action, or pushes the new data back to the controller for the view to present to the screen. The MVC method is something we've adopted her aswell, and the scarey part is we have also adopted an MVP approach for the "presentation" layer logic (especially in FlashMX) where you also have to have an OOP style of approach for just client-side sub-development. Keeping database logic independent of CFC's can be achieved in my book as this allows you the ability to not only make an application for SQL, but also mySQL and depending on your instatiation routes accordingly.. ie say we use the read from xml packet, and the master developer edits this file, and changes the dbtype from SQL to mySQL. Instead of doing a long winded SWITCH statement, it simply changes the direction of CFMX from looking at SQL to mySQL. The model in my view can be broken into two more layers, in that "domain" and database layer, in that you have: products.cfc > productsDB.cfc Inside the products.cfc you have a property caled this.dbType (defaults to null). The products.cfc extends to productsDB.cfc. When you instatiate the products.cfc in your init() call, you make a call to the XML Server configuration file, which then sets the dbType to SQL or mySQL. Then inside your productsDB.cfc you could have a switch statement (much like the fuseaction concept) whereby it routes the servers database calls to the appropriate style of dblookup. At the end of the day, you return the data in a standard format for all (sometimes you may need a manipulation routine to be run if it comes out long winded) but essentially you then can deploy your application(s) so that its compatible with an array of databases. So your users then can simply change one attribute from SQL to mySQL and the end users got a compatible application. Regards Scott Barnes --- 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/
