Hi,
I tend to use the PureMVC framework and would typically architecture
like this:
View = the UI interface i.e. form, grid, lsit etc.
(in PureMVC a Mediator handles responses from the UI and pushes to the
rest of the framework)
Controller = handles these responses and passes to the Model.
Model = interacts with the remoting aspect i.e. CF and passes the data
back out in an event system.
http://www.nutrixinteractive.com/blog/?page_id=111
Check that link for my WIKI and see my PureMVC AS3 / Flex / CF Demo -
Query a CFC
Cheers,
Simon
On 8 Oct 2008, at 16:58, shortgrass23 wrote:
This question is one part philosphical, one part technical. I am
trying to embrace the idea of an MVC framework and abstraction. I
started a new project with the following setup and am wondering if
this is logical and, if so, how will this benefit me in the future?
Thanks for any feedback.
I have a main MXML page, which I refer to as the parent, which would
be considered the controller. The controller knows all about the other
components that it calls. On the controller I have code that makes
components visible, adds event listeners to UI elements like buttons
within the components, and functions that respond when those listeners
"hear" something.
I have many component MXML pages, which have no reference within them
to the controller since they are not suppose to depend on the
controller. They contain UI elements, code to populate drop-down
boxes, public variables that the controller can poke values into, and
models that hold the data that the controller will send to the web
service, which in my case is a cfc.
The cfc has functions in it which call table-valued functions and
stored procedures.
This is so different than traditional CF programming, I can't even
tell if it makes sense or not.