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
