Hey Dave, There should be an article addressing just this in an upcoming issue of CFDJ.
In short: M = Your application's logic, probably a bunch of CFCs. V = How people "see" the data in your app, and make requests of it (probably .CFM) C = A "glue" layer that moves data between the view and the model MVC gets bastardized a little for Web purposes - in a desktop scenario, it wouldn't be unusual to have the V ask the M directly for data (state), but because we can't really support requests like that in an http environment, the C often takes on a role of helping to pass state from the M back to the V. > I'm kind of embarrassed to ask this, but I don't get it, so I'll just put it > out there... Dude, it's _absolutely_ nothing to be embarrassed about! I had to learn Flash to really get MVC. This stuff is not easy. > I'm not sure I get what's M, what's V, and what's C in some situations. For > instance, take a typical data-driven app: Enter the area, see a search > screen, submit it and get a record list back. Some areas have only a few > records, so there's no search screen; all recs are always shown as soon as > you enter the area. Some areas have several different search screens. > > How does this typical set of scenarios get put together in an MVC world? for > instance: Off the cuff, an implementation would probably look like this: M: A CFC that reads the list of records and applies any search criteria V: Displays a list of records or a form that allows search criteria C: Sends any criteria from the V to the M, and sets a variable that the V will "know" contains the resulting query > The controller gets the user's employees.list request, and detects that the > submit btn wasn't clicked, so it calls employees.view.show_search. User > submits that back to the controller, which now sees that the search has been > submitted, so it calls employees.model.do_query, then > employees.view.show_list. That sounds good to me. > Or does the controller always blindly call the > model and the view; the model detects that it shouldn't query because the > submit btn wasn't pressed, The model shouldn't know anything about the submit button - models should have no knowledge of views or their API. > Can anyone help me get a handle on how these kinds of decisions are > typically divided up between M, V, and C? Am I being clear here? A complete > goober? I'd use the purpose of the M, the V, and the C to make these decisions. IMHO, the most important thing to remember is that the M should have no knowledge of the V or the C. Another important thing to remember is that you will not get it "perfect" the first time. OO design is an iterative process, and as you design and develop your application, it's likely that there are portions that you will refactor. (We all knew the next paragraph was coming.) A framework can also help by aiding you in organizing your MVC application. If you're not used to OO development, I'd suggest checking out Fusebox, and specifically "MVC Fusebox". If you'd like to take a full-blown OO approach, there's Model-Glue (www.model-glue.com) and Mach-II (www.mach-ii.com). They will probably both have steeper learning curves, but Model-Glue is designed to be a little quicker to get up to speed with. -Joe -- Get Glued! The Model-Glue ColdFusion Framework http://www.model-glue.com ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
