As Barry would say: "CHAMPAGNE CF"
I rikey it lot, I'm going to roadtest your theories out! (this is what I like to see, more CFC ideas) :D Scott "Pat Branley" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > > 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/
