Pergunta sobre o design das implementações atuais de paginação


12

Eu verifiquei as implementações de paginação no asp.net mvc especificamente e realmente sinto que há algo menos eficiente nas implementações.

Antes de tudo, todas as implementações usam valores de paginação como abaixo.

public ActionResult MostPopulars(int pageIndex,int pageSize)
{

}

O que eu acho errado é o pageIndex e o pageSize totalmente devem ser membros da classe Pagination, caso contrário, dessa maneira, parece muito funcional. Além disso, simplifica a passagem desnecessária de paramater em níveis de aplicação.

A segunda coisa é que eles usam a interface abaixo.

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; }
} 

Se eu quiser rotear minha paginação para uma ação diferente, é necessário criar um novo modelo de exibição para encapsular o nome da ação nela ou mesmo o nome do controlador. Outra solução pode ser que, ao enviar esse modelo de interface para exibição, especifique a ação e o controlador codificados no método pager como parâmetro, mas estou perdendo totalmente a reutilização da minha visão, porque depende estritamente de apenas uma ação.

Outra coisa é que eles usam o código abaixo em vista

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

Se o modelo é IPagedList, por que eles não fornecem um método de sobrecarga como esse @Html.Pager(Model)ou ainda melhor @Html.Pager(). Você sabe que sabemos o tipo de modelo dessa maneira. Antes de cometer um erro, porque estava usando Model.PageIndex em vez de Model.PageNumber.

Outro grande problema é que eles dependem fortemente da interface IQueryable. Como eles sabem que eu uso o IQueryable na minha camada de dados? Eu esperava que eles funcionassem simplesmente com coleções que mantêm a persistência da implementação da paginação ignorante.

O que há de errado com minhas idéias de melhoria em relação às implementações de paginação? Qual é o motivo deles para não implementar suas paginações dessa maneira?


Parece-me bastante complexo. Não que eu tenha entendido exatamente qual é o problema, mas ... você realmente precisa usar os auxiliares integrados? Eu nem sabia que eles tinham um pager. Desenvolvi uma coleção de meus próprios auxiliares desde os dias do MVC 1 Beta, depois das minhas primeiras (e falhadas) tentativas de me dar bem com os auxiliares internos. Eu recomendo o mesmo para você. Se você está lutando com esses auxiliares, não é melhor do que WebForms, onde você estava lutando com os controles do servidor.

O ASP.NET MVC não possui auxiliares de paginação integrados, apenas existem implementações de paginação de terceiros.
Freshblood

Obrigado por esse pouco de informação. A questão é: por que você precisa de um? Não é um esforço implementá-lo por conta própria, assim como você deseja que seja.

Eu só queria saber que há algo errado nas minhas idéias. Eu quebrei alguns princípios fundamentais se não for assim porque todos eles seguiram mesmo projeto em suas implementações .. eu não entendo
Freshblood

se um código não pode resolver o problema de um programador, o código não tem valor, é melhor evitar usá-lo.
Shaheer

Respostas:


1

Como o user8685 afirmou: sua interface parece redundante às coisas e aos princípios existentes do MVC.

Tente o seguinte: as informações necessárias do IPagedList, como o índice da página, etc. devem ser implementadas na camada de lógica de negócios e alimentadas para a visualização / página por meio de um modelo genérico que pode ser alimentado de volta ao servidor e transmitido e processado com segurança. Por quê? Porque o que você está coletando aqui claramente é uma entrada para o seu sistema de informações e, como tal, pertence a camadas inferiores à interface do usuário.

Esse caminho pode não ser o melhor caminho a percorrer e certamente não é o mais rápido, mas deve facilitar a visualização do que você realmente precisa em termos de abstração e arquitetura de dados e, assim, ajudá-lo a remover a redundância.

Além disso, os auxiliares existentes geralmente contêm muita sobrecarga para uso simples e às vezes ofuscam a visão geral.


0

Ainda não usei este IPagedList ou ajuda, mas esta é a minha opinião:

A MostPopular(int pageIndex,int pageSize)é uma interface explícita, afirmando: retornarei apenas páginas das coisas MostPopular. Você me diz explicitamente qual página e seu tamanho.

Se eles tivessem feito um método de controlador, MostPopular(IPagedList<T> page)a interface fica mais confusa. Você está dizendo ao controlador a quantidade total de itens ou não?

Quando o controlador recupera sua fatia paginada específica dos dados, ele normalmente pode descobrir vários outros dados, como quantos itens existem no total. Nesse ponto, faz sentido retornar esses dados para uma exibição, para que eles possam usar seletivamente alguns deles.

Isso não significa que IPagedList é o modelo; ele também pode fazer parte de um modelo (uma propriedade nele). É provavelmente por isso que não há sobrecarga sem parâmetros.

Eles poderiam ter adicionado IPagedList como uma sobrecarga, mas você passaria um conjunto (um pedaço de dados paginado) para um pequeno auxiliar de pager que não precisa dos dados reais. Ele só precisa saber quantas páginas / itens e onde você está no momento para destacar o número da página e tal. Você diria ao ajudante muito mais do que ele precisa saber para fazer seu trabalho. A maneira como funciona agora tem acoplamento mais baixo, o que é uma coisa boa.


Eu só queria dizer que o parâmetro do método de ação pode ser um objeto que possui uma propriedade denominada PageIndex e PageSize, para que possamos validar o modelo com facilidade, porque alguém pode aumentar o tamanho da página para atacar o desempenho do servidor. E se eles forneceriam uma sobrecarga sem parâmetros, a sobrecarga sem parâmetros seria útil quando o modelo for IPagedList. Não há nada errado se eu estiver passando mais dados do que o auxiliar precisa. Não existe uma regra estrita como uma boa prática.
precisa saber é o seguinte

0

Dado que o que o cliente pede para o número da página e qual a probabilidade de ele variar é o tamanho da página, penso:

public ActionResult MostPopulars(int pageIndex,int pageSize)

É uma maneira bastante sensata de fazer isso. Eu tenho visto variações em que um ennum de (primeiro, próximo, anterior, último) foi usado, mas na verdade é apenas uma maneira estranha de dizer "pageIndex".

Eu reiteraria que o tamanho da página varia e deve variar, dependendo do visualizador envolvido, você deve obter diferentes padrões para celulares, portáteis e estações de trabalho de tela grande, além disso, em muitos casos, é sensato deixar o usuário final escolher quantos itens constituem uma página.

Sei que isso resulta em muitos parâmetros passando dentro de uma estrutura MVC, mas todo o conceito de paginação quebra o MVC - sua lógica de negócios precisa conhecer a apresentação para que a paginação funcione, portanto sempre será uma bagunça.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.