0

When working with some project, their are special kind of model class, which deal with list or batch data content, eg:

class UserBatchOperate
{
    /* Do some logic work, then use db access layer to retrieve data */
    public function listUserHaveSomeBadge() {}

    /* Do same operate on all user fit the condition */
    public function assignBadgeToUserRegistedBefore2012() {}
}

(I think this is model logic, not job of db access layer, PDO or ORM. In other words, I use a simple db access layer to do CRUD, leave logic part in model.)

My question is, this kind of model class is more likely a function set, most of it's method havn't inner relation, is this the proper way to do this ?

Fwolf
  • 671
  • 4
  • 8
  • Why are you dumping both domain and persistence logic in same class? Also, `listUserHaveSomeBadge()` should not be part of `User` class .. and you probably should pick a name that does not induce spontaneous hemorrhaging. – tereško Nov 28 '13 at 15:29
  • @tereško The second class is plan 2, I add list/batch method to User class, and think it's not a good way. – Fwolf Nov 28 '13 at 15:32
  • Please ignore User class, I have remove it. Now my UserList class is only a function collector, is there better plan ? – Fwolf Nov 28 '13 at 15:35
  • Maybe [this](http://stackoverflow.com/a/11943107/727208) gives you some ideas for how to approach your problem. – tereško Nov 28 '13 at 15:38

1 Answers1

0

The functions you have in the UserBatchOperate class are clearly API methods of the user. You could extract it to another class, which merly operates on the persistance layer - models and collections. This class should not perform any CRUD operations on its own.

Example API extracted

The advantage of such solution is that you can go extract even more specific APIs for the user as you require them. For example in the future you may want to have different API for manipulating user data, and different for only retrieving the data. It can be as simple as splitting the API class into two different ones.

EDIT:

Another advantage of such solution is that you could expose entire API class as an WebService (SOAP or REST) should you ever have the need to do so.

Maciej Sz
  • 9,025
  • 6
  • 37
  • 51
  • My UserBatchOperate class is doing the job of UserCollection class you said, I have another class to deal with SINGLE instance(eg: User class). I dislike UserBatchOperate is because it's methods have no inner relation, something don't look like proper OOP way. – Fwolf Nov 28 '13 at 15:50
  • `UserCollection` should not have the methods you have in `UserBatchOperate`. It should only operate on underling persistance (db table) via set of filters. See [SRP](http://en.wikipedia.org/wiki/Single_responsibility_principle). – Maciej Sz Nov 28 '13 at 15:54
  • Please, stop referring to domain objects and collections of domain objects as "models". – tereško Nov 28 '13 at 16:04
  • @tereško I have read link you given, with this answer I conclude: Collection is to treat condition, set filters, but actual db operate are done in another class. In your link its Mapper class, in this answer its UserApi class, am I understand currectly ? – Fwolf Nov 28 '13 at 16:11
  • @MaciejSz I got why you put the 2 method in UserApi and your opinion about Collection class(provide filter to Api class). Anyway UserApi have these list..() mark..() method now, if rename UserBatchOperate to UserApi and make it use Collection class as parameter of method, we're back to start point. Maybe I'm asking wrong question, there must be some class to hold these method, but your opinion of Collection or tereško's Mapper class inspired me a lot, thanks! – Fwolf Nov 28 '13 at 16:33