(12-27-2014, 06:51 PM)sneakyimp Wrote: 3) Payment and business-related classes such as a 'payment router' class. I.e., business logic that guides users through a series of purchase-related pages. More specifically, a class that helps redirect a user to the optimal page based on their account status, prior purchases, session data, and other considerations. Because this is business logic so tightly linked to our business processes and data, I'm strongly inclined to call this a model, but not 100% sure.
7) Miscellaneous code to enforce user privileges derived from user access levels, subscriptions, and purchasing behavior.
This is stuff like "don't let users bid on products unless they have an account with access_level=2" and such. I wonder if this is controller or model?
It may be personal preference, but I think #3 is a model. I try to do as little as possible in my controllers: validate the request, get info from a model, send it to the browser. I'd want something like this in my controller for #3:
$user = usermodel->get($id); // or get it from the session or auth lib
$view = pagemodel->getOptimal($user);
For #7, it really depends on how you are doing authentication. I like to do it in a controller constructor hook, some might do it in a MY_Controller that they extend, or you could write a custom validation rule. You could add a hasBidAccess function to your authentication library that calls a function in a datamodel that does a query. There are a lot of options.
