Just to add to this discussion, the 'model' in mvc will contain
services, gateways, value objects, etc. These components (cfc based 99%
of the time) interact with either another application (which may be an
entirely different MVC app) or a database engine (which you could yet
again be considered to be a separate external app) that simply provides
data. Important thing to note, most databases are relational so the
model will convert that logic to an object oriented picture for the app
to use. So instead of using a query object like a spreadsheet, you
convert to a list of objects (like value objects). Look at Transfer and
the new CF9 Hibernate features to see how this logic works.
Now, the key difference between any MVC framework is in the controller
logic. The views should be essentially the same: containing things like
forms, data lists, and similar presentation logic. The 'view' contains
cfoutput, html, javascript, but NOT service calls like cfquery or
cfhttp. Service calls are in the 'model'. The model can actually be
rather complex in itself, but should again be independent of the MVC
logic. Your 'views' and 'model' should not be very different based on
your framework choice. However, the controller is where the real
differences exist between the frameworks. One is not naturally better
than another. Some don't scale as well like a front controller
frameworks, but most of the decisions at this point deal with your
comfort in programming.
In the CF MVC world, you have several different types of controllers to
work with..
Framework
Controller Logic
Explanation (what does that fancy tern mean)
Homebaked
Usually a Front Controller
Direct call to services (usually very tighly coupled between view logic
and model service calls)
Fusebox
Front Controller
Direct call to services (tight coupling between view and model)
Mach-II
Implicit Invocation (Observer pattern) Events are fired which a
listener then handles and calls services (loose coupling between views
and model)
Model-Glue
Implicit Invocation (Observer pattern) Events are fired which a
listener then handles and calls services (loose coupling between views
and model)
Coldbox
Convention over Configuration (CoC)
Also event driven but no xml configuration. Naming and convention
handles the controlling logic (medium coupling in my view - but some may
argue this point)
Coldspring is not a MVC framework in itself. It's a object creation tool
to help with object (cfc) dependencies and such. If you do use one the
advance frameworks and properly code out your 'model', then coldspring
will come in very handy. As a fyi, it follows the factory design and
Inversion of Control (IoC) patterns.
-------------------------------------------------------------
To unsubscribe from this list, manage your profile @
http://www.acfug.org?fa=login.edituserform
For more info, see http://www.acfug.org/mailinglists
Archive @ http://www.mail-archive.com/discussion%40acfug.org/
List hosted by http://www.fusionlink.com
-------------------------------------------------------------
