Should objects in ORM contain operations other than CRUD?

Question

Let's say I have a User object for performing CRUD operations using ORM:

//Create a new User
$user = new User();
$user->name = "John Smith";
$user->age = 30;
$user->email = 'john@smith.com;
$user->save();

Similiar operations would also be avaliable for Read, Update and Delete.

But what about cases such as these:

• deleteAllUsers() //delete all users
• getAllUsers() //get all users
• promoteUser() //change the user's 'rank' (not permissions) within a website
• addReputationPoints() //give the user x amount of reputation points

Would these type of operations go into the User class? If not, where should they go? Should I have a class called UserManager that deals with these operations?

Answer 1

Usually, the User class would extend an ORM class that provides the standard CRUD interface. The additional functions you talk about would very well fit within the User class itself.

It is always good practice to make 'fat models' and skinny controllers, i.e. put all logic that is directly related to data manipulation in the models, and only the 'overarching' logic in the controllers.

See e.g. here for more info http://weblog.jamisbuck.org/2006/10/18/skinny-controller-fat-model

Answer 2

It depends on how you architecture your ORM solution.

My approach would be to enclose collective actions (made on multiple records at once) into some class representing eg. database table storing users or the one responsible for the basic ORM actions - depending whether they are table-specific or not.

Answer 3

In my most favorite framework (Kohana), we have:

ORM::factory('user')->where(<whatever condition required>)->find_all();

and the corresponding delete() (replacing find_all() above). Are you writing your own ORM library? If yes, then you can make operations that deal with more than one record as class methods instead of instance methods. It's up to your design, however. Kohana, for instance, still make it instance method.