That's one way of achieving the goal but should not be a means to an end. Ideally you would identify new model objects to be born, for instance is the controller dealing a lot with adding fields to some "grid" object before pushing it to the view, if so you could sub-class that grid object for that module so the implementation logic resides in a subclass of the grid class instead of the controller instantiating the abstract grid and setting it "procedurally".
A useful way to think about this is reading the chapter called "transaction scripts" and "page controllers" in POEAA, I think those patterns capture the essence of the "fat controller smell". Sudheer Satyanarayana wrote: > > On Friday 18 September 2009 07:10 PM, Ryan Chan wrote: >> Hello, >> >> I have a controller that contains too many line of codes, which made >> the controller too large. >> >> So I want to split each action into eactly one class files. >> >> Is it recommended? If not, what are the recommended way to make the >> controller "thin"? >> >> > Consider splitting your code into multiple controllers and perhaps > modules. Do you have model classes by the way? > > > -- > > With warm regards, > Sudheer. S > Business: http://binaryvibes.co.in, Tech stuff: http://techchorus.net, > Personal: http://sudheer.net > > > -- View this message in context: http://www.nabble.com/Split-controller-actions-into-multiple-classes-tp25508838p25600601.html Sent from the Zend Framework mailing list archive at Nabble.com.
