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 ?

  • It looks quite complex to me. Not that I've quite understood what exactly the problem is, but... do you really need to use the built-in helpers? I didn't even know they had a pager. I've developed a collection of my own helpers since the days of MVC 1 Beta after my first (and failed) attempts to get along with the built-in helpers. I recommend the same to you. If you're struggling with those helpers then it's no better than WebForms where you were struggling with server controls.
    – user8685
    Jun 12, 2011 at 10:34
  • ASP.NET MVC has no built in pagination helpers just there are third party pagination implementations.
    – Freshblood
    Jun 12, 2011 at 10:38
  • Thank you for that bit of information. The question is, why do you need one? It's no effort to implement it on your own, just like you want it to be.
    – user8685
    Jun 12, 2011 at 11:02
  • I just wanted to know that is there something wrong about my ideas . Did i break some core principles if not so why all of them followed same design on their implementations .. i don't get it
    – Freshblood
    Jun 12, 2011 at 11:17
  • if a code cant solve a programmer's problem, the code has no value, you better avoid using it.
    – Shaheer
    Jun 13, 2011 at 18:54

3 Answers 3


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.


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.

  • I just wanted to say action method parameter could be object that has a property named PageIndex and PageSize so in this way we could validate model easily because someone can push huge amount of page size for attacking server performance. And if they would provide parameterless overload so parameterless overload would be useable when model is IPagedList. There is no anything wrong if i am passing more data then helper needs. There is no such as strict rule as best practice.
    – Freshblood
    Apr 22, 2012 at 18:49

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.