Question on design of current pagination implementations

Question

I have checked pagination implementations on asp.net mvc specifically and i really feel that there is something less efficient in implementations.

First of all all implementations use pagination values like below.

public ActionResult MostPopulars(int pageIndex,int pageSize)
{

}

The thing that i feel wrong is pageIndex and pageSize totally should be member of Pagination class otherwise this way looks so much functional way. Also it simplify unnecesary paramater pass in tiers of application.

Second thing is that they use below interface.

public interface IPagedList<T> : IList<T>
{
    int PageCount { get; }
    int TotalItemCount { get; }
    int PageIndex { get; }
    int PageNumber { get; }
    int PageSize { get; }
    bool HasPreviousPage { get; }
    bool HasNextPage { get; }
    bool IsFirstPage { get; }
    bool IsLastPage { get; }
} 

If i want to routing my pagination to different action so i have to create new view model for encapsulate action name in it or even controller name. Another solution can be that sending this interfaced model to view then specify action and controller hard coded in pager method as parameter but i am losing totally re-usability of my view because it is strictly depends on just one action.

Another thing is that they use below code in view

Html.Pager(Model.PageSize, Model.PageNumber, Model.TotalItemCount)

If the model is IPagedList why they don't provide an overload method like @Html.Pager(Model) or even better one is @Html.Pager(). You know that we know model type in this way. Before i was doing mistake because i was using Model.PageIndex instead of Model.PageNumber.

Another big issue is they strongly rely on IQueryable interface. How they know that i use IQueryable in my data layer ? I would expected that they work simply with collections that is keep pagination implementation persistence ignorant.

What is wrong about my improvement ideas over their pagination implementations ? What is their reason to not implement their paginations in this way ?

Answer 1

As user8685 stated: your interface seems redundant to existing MVC stuff and principles.

Try this: information you require from IPagedList, like page index etc. should be implemented in business logic layer and fed to the view/page through a generic model that can be fed back to the server and safely cast and processed there. Why? Because what you are collecting here clearly is an input to your information system and as such belongs to layers lower than UI.

This way may not be the best way to go and is certainly not the quickest, but should make it easier to see what you really need in terms of abstraction and data architecture and thus help you remove redundancy.

Also, existing helpers often contain too much overhead for simple usage and sometimes obfuscate the big picture.

Answer 2

Haven't used this IPagedList or helper thingy but this is my take:

The MostPopular(int pageIndex,int pageSize) is an explicit interface stating: I will only return pages of MostPopular things. You explicitly tell me which page and it's size.

If they had made a controller method MostPopular(IPagedList<T> page) the interface gets more confusing. Are you telling the controller the total amount of items or not?

When the controller retrieves your specific paged slice of the data it can typically discover various other data, like how many items there are total. At this point it makes sense to return such data to a view, so it can selectively use some of it.

This doesn't mean that IPagedList is the model, it could just as well be part of a model (a property on it). This is likely why there is no parameter-less overload.

They could have added IPagedList as an overload but then you would be passing a set (a paged chunk of data) to a little pager helper that doesn't need the actual data itself. It just needs to know how many pages/items and where you are at at the moment so it can highlight the page number and such. You would tell the helper far more then it needs to know to do it's job. The way it works now it has lower coupling, which is a good thing.

Answer 3

Given that what the client asks for a the page number and what the client is most likely to vary is the page size I think:

public ActionResult MostPopulars(int pageIndex,int pageSize)

Is a pretty sensible way of doing this. I have seen variations where an ennum of (first, next, prev, last) was used but really its just an awkward way of saying "pageIndex".

I would reiterate that page size will and should vary a lot, depending on the viewer involved you should get different defaults for mobiles, portables and big screen workstations, plus, in many cases it is sensible to let the end user choose how many items constitute a page.

I know this results in a lot of parameter passing within an MVC framework, but the whole concept of paging breaks MVC -- your business logic needs to know about presentation in order for the paging to work so its always going to be messy.