I've been using fat model for a while now. It was difficult for me to get over what now appear to insignificant problems but at the time they looked huge.
As the model's primary responsibility is to deal with data, I found it useful to always return something more than a boolean. So most of my model functions return a mixed data array. Part of that result array is a status structure which I can then refer to from the controller to display errors or redirect etc. This also allows the model to process a set of data and return an iterative list of errors. As an example I have a csv import which will process the first 100 rows of an import. Each row has the potential of creating an error, and the loop moves on to the next row. all these errors are returned in a single result. The model then passes the file to a background task to process the remainder of the rows. The controller displays via the view to the user the results of the first 100 rows along with the list of errors. I did this because some of these files are huge and would timeout. I can process 100 rows fairly quick and return control back to the user where they can see those newly imported records along with any errors. A second reason for this process is the model code doesn't know if it is being called by human interaction or via a cron script in either case the errors are also written to a logger which the user can review at any point in the app. In a previous post to this thread you mentioned you needed to redirect in certain conditions. Don't get your business logic (model) confused with your application flow (controller). A lighter controller doesn't mean there isn't any logic in those functions it just means there is less logic in them. Logic to control redirects definitely does belong in the controller and your model needs to be able to give enough information back to the controller to make those decisions. I've also found building test for the models is a lot easier than for the controller. If your using test do your best to write the test first. If your not using test, at least think in the mindset of the model code being called from human interaction as well as from a headless script. This will force you to deal with errors in a batch mode instead of one off exceptions. Overall your on the right track your making your model fat and you have identified the model is too deep for direct human interaction. I think there are many ways to deal with this without breaking the MVC pattern. My method explained above may seam too much for some, but having the errors logged and being able to review them has helped in identifying pieces of code which were in need of rework. A type of live profiling. Not so much of the performance but more so on quality and intuitive use or to identify poor assumptions on my part about the ability of my users. Check out the new CakePHP Questions site http://cakeqs.org and help others with their CakePHP related questions. You received this message because you are subscribed to the Google Groups "CakePHP" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/cake-php?hl=en
