Personally I'd opt for the Filter object over method parameters as I find it much easier to add a property to the object versus a parameter to a function call. I thought about the list idea but opted to go the filter route as sometimes w/in the list we have a parameter this is itself a list. So we went w/ the object approach to clearly define what all the options are. In addition, within our app our controller uses a 'helper' as an intermediary between the UI and the model calls. The helper knows about the form or url elements and the Filter object and then loads the Filter object accordingly. Our controller creates the Filter object, passes it to the helper and then passes the result to the model which passes back the results to a view. This approach is working for us but there are certainly may other ways of doing the same thing. The difference b/w how a Gateway/DAO interact and what each does are really implementation preferences. In principle I believe Nando and I are both doing pretty much the same thing in that something is given an object and loads it from the db or something runs a query to return multiple rows. Both of the something's are abstracted into a method call w/in a class somewhere. So I think we are just implementing the idea or concept in different ways.
---------------------------------------------------------- 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]
<<attachment: winmail.dat>>
