Your controller really need to facilitate what is needed.
You are going to typically invoke an event to a listener. The listener is going to assign which controller will be used. Once the controller is invoked, the method will take in stateful information. I am not a fan of having shared scopes in my controllers. I will create a generic and configurable facade in my ColdSpring repository that will inject a shared scope into my controllers. The controller will take the facade's information and invoke the model along with the event's state. The model is also a bean defined in my ColdSpring repository that has all of its argument contructors created. The model is invoked with the stateful data passed to it from the facade and the event. The data is returned is returned to the controller that then in turn will assign the data in the view. The view knows nothing of shared scopes. The controller knows nothing of shared scopes and what the view looks like. The model knows nothing at all. Why is this good? The model now can be used for any framework or even web service (AJAX). The view is easy to debug as the invocation of all data is in one central place, the controller. The controller now can be converted between frameworks when all that it needs to know is an event bean, the location of the view collection and the facade for shared information. Eventually, your code is abstracted enough that you can mix and match pieces in between frameworks, adhoc invocation and even some parts can be used for more graphical environments like Flex. Lastly, the likelihood of switching between framework is small in the short term, but can you plan for the long term? Teddy On 3/7/07, Jaime Metcher <[EMAIL PROTECTED]> wrote:
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]
-- Teddy R. Payne G-Talk: [EMAIL PROTECTED] Adobe Certified ColdFusion MX 7 Developer Atlanta ColdFusion User Group (ACFUG) Atlanta Flash & Flex User Group (AFFUG) 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]
