Pregunta sobre el diseño de las implementaciones actuales de paginación


12

He comprobado específicamente las implementaciones de paginación en asp.net mvc y realmente siento que hay algo menos eficiente en las implementaciones.

En primer lugar, todas las implementaciones usan valores de paginación como a continuación.

public ActionResult MostPopulars(int pageIndex,int pageSize)
{

}

Lo que me parece incorrecto es pageIndex y pageSize totalmente debería ser miembro de la clase Pagination, de lo contrario, esta forma parece mucho más funcional. También simplifica el pase de parámetros innecesarios en niveles de aplicación.

Lo segundo es que usan la siguiente interfaz.

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

Si quiero enrutar mi paginación a una acción diferente, entonces tengo que crear un nuevo modelo de vista para encapsular el nombre de la acción o incluso el nombre del controlador. Otra solución puede ser enviar este modelo con interfaz para verlo y luego especificar la acción y el controlador codificados en el método de buscapersonas como parámetro, pero estoy perdiendo la reutilización total de mi vista porque depende estrictamente de una sola acción.

Otra cosa es que usan el siguiente código a la vista

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

Si el modelo es IPagedList, ¿por qué no proporcionan un método de sobrecarga similar @Html.Pager(Model)o incluso mejor @Html.Pager()? Sabes que conocemos el tipo de modelo de esta manera. Antes estaba cometiendo un error porque estaba usando Model.PageIndex en lugar de Model.PageNumber.

Otro gran problema es que dependen en gran medida de la interfaz IQueryable. ¿Cómo saben que uso IQueryable en mi capa de datos? Esperaría que funcionen simplemente con colecciones que mantengan la persistencia de la implementación de paginación ignorante.

¿Qué hay de malo en mis ideas de mejora sobre sus implementaciones de paginación? ¿Cuál es su razón para no implementar sus paginas de esta manera?


Me parece bastante complejo. No es que haya entendido exactamente cuál es exactamente el problema, pero ... ¿realmente necesita usar los ayudantes incorporados? Ni siquiera sabía que tenían un buscapersonas. Desarrollé una colección de mis propios ayudantes desde los días de MVC 1 Beta después de mis primeros (y fallidos) intentos de llevarme bien con los ayudantes incorporados. Te recomiendo lo mismo. Si estás luchando con esos ayudantes, entonces no es mejor que WebForms donde estabas luchando con los controles del servidor.

ASP.NET MVC no tiene ayudantes de paginación integrados, solo hay implementaciones de paginación de terceros.
Freshblood

Gracias por esa información. La pregunta es, ¿por qué necesitas uno? No es un esfuerzo implementarlo por su cuenta, tal como lo desea.

Solo quería saber que hay algo mal en mis ideas. Me rompo algunos principios básicos, si no ¿por qué todos siguieron mismo diseño en sus implementaciones .. i no lo entiendo
Freshblood

Si un código no puede resolver el problema de un programador, el código no tiene valor, es mejor evitar usarlo.
Shaheer

Respuestas:


1

Como dijo user8685: su interfaz parece redundante a las cosas y principios MVC existentes.

Intente esto: la información que necesita de IPagedList, como el índice de página, etc., debe implementarse en la capa de lógica de negocios y alimentarse a la vista / página a través de un modelo genérico que se puede enviar al servidor y transmitir y procesar de forma segura allí. ¿Por qué? Porque lo que está recopilando aquí claramente es una entrada a su sistema de información y, como tal, pertenece a capas inferiores a la IU.

Es posible que este camino no sea el mejor, y ciertamente no es el más rápido, pero debería facilitarle ver lo que realmente necesita en términos de abstracción y arquitectura de datos y, por lo tanto, ayudarlo a eliminar la redundancia.

Además, los ayudantes existentes a menudo contienen demasiados gastos generales para un uso simple y, a veces, ofuscan el panorama general.


0

No he usado esta IPagedList o ayudante, pero esta es mi opinión:

La MostPopular(int pageIndex,int pageSize)es una interfaz explícita que indica: solo devolveré páginas de las cosas más populares. Me dices explícitamente qué página y su tamaño.

Si hubieran hecho un método de controlador, MostPopular(IPagedList<T> page)la interfaz se vuelve más confusa. ¿Le está diciendo al controlador la cantidad total de artículos o no?

Cuando el controlador recupera su porción paginada específica de los datos, generalmente puede descubrir otros datos, como cuántos elementos hay en total. En este punto, tiene sentido devolver dichos datos a una vista, por lo que puede usar selectivamente algunos de ellos.

Esto no significa que IPagedList sea el modelo, también podría ser parte de un modelo (una propiedad en él). Esto es probable por qué no hay sobrecarga sin parámetros.

Podrían haber agregado IPagedList como una sobrecarga, pero luego estaría pasando un conjunto (un fragmento de datos paginado) a un pequeño ayudante de buscapersonas que no necesita los datos reales. Solo necesita saber cuántas páginas / elementos y dónde se encuentra en este momento para que pueda resaltar el número de página y tal. Le diría al ayudante mucho más de lo que necesita saber para hacer su trabajo. La forma en que funciona ahora tiene un acoplamiento más bajo, lo cual es bueno.


Solo quería decir que el parámetro del método de acción podría ser un objeto que tiene una propiedad llamada PageIndex y PageSize para que así podamos validar el modelo fácilmente porque alguien puede presionar una gran cantidad de tamaño de página para atacar el rendimiento del servidor. Y si proporcionarían una sobrecarga sin parámetros, la sobrecarga sin parámetros sería útil cuando el modelo sea IPagedList. No hay nada malo si estoy pasando más datos que las necesidades de ayuda. No existe una regla estricta como la mejor práctica.
Freshblood

0

Dado que lo que el cliente solicita para el número de página y lo que es más probable que varíe es el tamaño de la página, creo:

public ActionResult MostPopulars(int pageIndex,int pageSize)

Es una forma bastante sensata de hacer esto. He visto variaciones en las que se usaba un ennum de (primero, siguiente, anterior, último) pero en realidad es solo una forma incómoda de decir "pageIndex".

Reitero que el tamaño de la página variará y debería variar mucho, dependiendo del espectador involucrado, debería obtener diferentes valores predeterminados para móviles, portátiles y estaciones de trabajo de pantalla grande, además, en muchos casos es sensato permitir que el usuario final elija cuántos elementos constituyen una página.

Sé que esto da como resultado que se pasen muchos parámetros dentro de un marco MVC, pero todo el concepto de paginación rompe MVC: su lógica de negocios necesita saber acerca de la presentación para que la paginación funcione, por lo que siempre será complicado.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.