Joe, There are lots of ways to skin a cat. A surprising number of them work. That said, my 2c:
If you can specify an operation independently of user input and display output, put it in the model layer. I'd think "Get the next x records starting from row y ordered by z" falls into this category. Working out what x, y and z should be in a particular case depends on user input (did they click back or next? what's the current paging size?) so it goes into the controller. The distinction between the view and the controller is much less important than making sure you have a clean separation from the model. Again, there are a number of variations here. In classic Smalltalk/GUI MVC, which is actually a very complex beast, the view asks the model for data. What a lot of people seem to do for web apps is have a very lightweight view that really only controls layout, and have all the data fed to it by the controller. It's also worth noting that it's common practice to divide the model layer further into data access (DAOs and Gateways) and business logic. All your SQL and usually any caching logic would go in the data access sublayer. Only the business logic, not the controller or view, talks to the data access layer. One of the payoffs is that further down the track you can replace this sublayer with an ORM framework like Transfer or Reactor, or use a code generator like Illudium to give you a head start on it. I understand why you might want to cache the recordset - by all means do that. However, my preferred approach would be to either only return the desired records from the database, or to use a comprehensive caching solution like that built in to Transfer. It might just be me, but I think cache inconsistencies have wasted more debugging hours than just about anything else on the planet. Jaime Metcher -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Joe Lakey Sent: Thursday, 8 March 2007 5:27 AM To: [email protected] Subject: [CFCDEV] Practical MVC question I'm developing a survey application, and right now, I'm working on the reporting part of the app. The survey results are in a table 'Result'. The user's access is limited to certain records based on management level and organization. The user is able to filter results on fiscal year and quarter or on a date range. My thinking is that the database query should be in a CFC in the model layer and should return all survey results to which the user has access. The filtering (and sorting and paging) would be in a controller in the session scope. The controller would cache the entire recordset from the model layer and return the appropriate filtered, sorted data to the view layer (cfm page) as a query or structure in the Request scope. Is this a correct application of the MVC framework? Anything that could be done better? Thanks in advance, Joe You are subscribed to cfcdev. To unsubscribe, please follow the instructions at http://www.cfczone.org/listserv.cfm CFCDev is supported by: Katapult Media, Inc. We are cool code geeks looking for fun projects to rock! www.katapultmedia.com An archive of the CFCDev list is available at www.mail-archive.com/[email protected] You are subscribed to cfcdev. To unsubscribe, please follow the instructions at http://www.cfczone.org/listserv.cfm CFCDev is supported by: Katapult Media, Inc. We are cool code geeks looking for fun projects to rock! www.katapultmedia.com An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
