I think you have the right idea there. In order to maintain single responsibility, your User()
class should not be involved with the fetching and updating of the table. It should merely represent a single user, and it's functions should be directly related to that. If you start having your User()
functions and the functions of a table mixed together, you break Single Responsibility. For this reason, I go with the second approach, and that's how it seems to work in the frameworks I've worked with
In Zend Framework, classes that extend Zend_Db_Table
handle the table manipulation, and return classes that extend Zend_Db_Table_Row
. In Zend Framework, Zend_Db_Table_Row
has a save
and delete
method, which calls back to the table to do the actual saving and deleting. I think this stays in line with sing responsibility, as you consider that responsibility to do with that row directly, not just a model separated from the row. Still, you have two classes. A table class and a row class
In Doctrine (I'm new to this, so I'm not familiar with advanced usages), each model represents a single row in the table, even so far as defining what columns are in the row. The rows are fetched and updated and created by the Doctrine Repository. If you require a repository just for your Table, then you do that but it's a separate class from User()
To sum up, to keep in line with Single Responsibility, I'd have UsersTable()::fetchAll()
return User[]
. Personally, I'd have User
be able to call on UsersTable
to update or delete the row, but that's simply a personal preference.