There's something interesting about all this, and it goes to the heart of API design and program evolution. This is a bit of a ramble but I was curious what others thought on the subject.
Suppose you have a parent object with children. Call them Order and OrderLine, just for fun. Anyone who does back-of-the-envelope object design will come up with something like an Order having many OrderLines via a List or array getter:
[code]public List<? extends OrderLine> getOrderLines();[/code]
I wonder: should domain object API design just always take into account paging concerns? Should that be:
[code]public List<? extends OrderLine> getOrderLines(final int startingIndex, final int numberOfLines);[/code]
...?
We all start out by blindly doing the getter/setter/Javabean/property thing, but I wonder...I wonder if paging shouldn't make it into the domain layer as a standard architecture component--maybe even a footnote in a JavaBeans specification update.
This is a contrived example because you would hopefully never make an Order that was so big that paging would actually be a concern, but you see what I mean.
Less contrived: What about other areas of an application? System.getUsers(), for example, might be one of those APIs where you start out by thinking that your application won't be very popular, but then it becomes the next MySpace.
So what's my point? I guess to the extent I have one it's just that it's easy to wave our hands and say "use JPA's paging facilities", but those concerns bubble up to the domain layer.
It would be interesting to hear where and how others have brought paging "up" into their domain layer.
Best,
Laird
[Message sent by forum member 'ljnelson' (ljnelson)]
http://forums.java.net/jive/thread.jspa?messageID=244879