Le 03/07/15 08:49, Xu, Yaning a écrit : > Kai, > > Thanks for your suggestions. It's good to me.
My percezption is that the getIdentities() method should be made specific, per backend. If a backend supports paged search and sort, fine, iyt can use it. If it's not, then it should use a default implementation. In any cases, the user should not be aware of what's going on behind the curtain. The best way to acheive this is to have the getIdentities() return a Cursor, which can be handled by any client. This cursor will allow the user to move forward or backward, regardless of the number of elements in the cursor. You can have a look at the Cursor interface we are using in ApacheDS : http://svn.apache.org/viewvc/directory/shared/trunk/ldap/model/src/main/java/org/apache/directory/api/ldap/model/cursor/ Side note : in the SQL world, this is the same approach. Once common mistake though in this world, when design (G)UI which expose pages of elements taken froma cursor is to proceed in two steps : - first do a SELECT COUNT(*) WERE blah - second, depending on the number of elements, proceed with a single page, or manage pagination locally, with a second request to the server, fetching the real entry. This is *idiotic* ! Doing that, you make the server do the same work twice : the SELECT COUNT(*) is as costly as the second request, and it's totally useless, unless you really want to expose the number of elements on the screen, which is rare. The rational is that when you do a normal request, the Cursor API allows you to define the number of elements you'll get back on the client side (default to 10, most of the time). That means the cursor implementation on the client side will cache N elements, no matter what, because the server will send N elements anyway. All in all, define a getIdentities() interface, with an abstract implementatiuon that fetches everything, and specific implementations that bypass this abstract implementation.
