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?
fuente
Respuestas:
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.
fuente
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.
fuente
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:
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.
fuente