현재 페이지 매김 구현의 디자인에 대한 질문

특히 asp.net mvc에서 페이지 매김 구현을 확인했으며 실제로 구현에 덜 효율적인 것이 있다고 생각합니다.

우선 모든 구현은 아래와 같은 페이지 매김 값을 사용합니다.

public ActionResult MostPopulars(int pageIndex,int pageSize)
{

}

내가 잘못 느낀 것은 pageIndex와 pageSize가 Pagination 클래스의 멤버 여야한다는 것입니다. 또한 적용 계층에서 불필요한 매개 변수 통과를 단순화합니다.

두 번째는 인터페이스 아래에서 사용한다는 것입니다.

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

페이지 매김을 다른 액션으로 라우팅하려면 액션 이름 또는 컨트롤러 이름으로 캡슐화하기위한 새보기 모델을 만들어야합니다. 또 다른 해결책은이 인터페이스 모델을 보내서 호출기 메소드에서 매개 변수로 하드 코딩 된 액션 및 컨트롤러를 지정하지만 하나의 액션에만 엄격하게 의존하기 때문에 뷰의 재사용을 완전히 잃어 버릴 수 있습니다.

또 다른 것은 그들이보기에서 아래 코드를 사용한다는 것입니다.

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

모델이 IPagedList 인 경우 왜 @Html.Pager(Model)또는 더 나은 방법으로 과부하 방법을 제공하지 않는가 입니다 @Html.Pager(). 우리는 이런 식으로 모델 유형을 알고 있습니다. Model.PageNumber 대신 Model.PageIndex를 사용했기 때문에 실수하기 전에.

또 다른 큰 문제는 IQueryable 인터페이스에 크게 의존한다는 것입니다. 데이터 계층에서 IQueryable을 사용한다는 것을 어떻게 알 수 있습니까? 나는 그것들이 페이지 매김 구현 지속성을 무지한 컬렉션으로 간단하게 작동 할 것으로 기대했다.

페이지 매김 구현에 대한 개선 아이디어에 어떤 문제가 있습니까? 이 방법으로 페이지 매김을 구현하지 않는 이유는 무엇입니까?

user8685가 말했듯이 : 인터페이스는 기존 MVC 물건과 원칙에 중복되는 것처럼 보입니다.

이것을 시도하십시오 : 페이지 색인 등과 같은 IPagedList에서 필요한 정보는 비즈니스 로직 계층에서 구현되고 서버로 다시 공급되어 안전하게 캐스팅되고 처리 될 수있는 일반 모델을 통해보기 / 페이지로 공급되어야합니다. 왜? 여기서 수집하는 것은 정보 시스템에 대한 입력이므로 UI보다 낮은 계층에 속하기 때문입니다.

이 방법은 가장 좋은 방법이 아니며 가장 빠르지는 않지만 추상화 및 데이터 아키텍처 측면에서 실제로 필요한 것을 쉽게 볼 수 있도록하여 중복성을 제거하는 데 도움이됩니다.

또한 기존 도우미에는 간단한 사용을 위해 너무 많은 오버 헤드가 포함되어 있고 때로는 큰 그림을 난독 처리하기도합니다.

이 IPagedList 또는 도우미를 사용하지 않았지만 이것이 내 취향입니다.

이것은 MostPopular(int pageIndex,int pageSize)명백한 인터페이스입니다. 나는 MostPopular 것들의 페이지 만 반환 할 것입니다. 어떤 페이지와 크기를 명시 적으로 알려주십시오.

컨트롤러 메소드를 만든 경우 MostPopular(IPagedList<T> page)인터페이스가 더 혼란스러워집니다. 컨트롤러에 총 항목 수를 알려주고 있습니까?

컨트롤러가 특정 페이징 된 데이터 조각을 검색하면 일반적으로 총 항목 수와 같은 다양한 다른 데이터를 검색 할 수 있습니다. 이 시점에서 그러한 데이터를 뷰로 반환하는 것이 합리적이므로 일부를 선택적으로 사용할 수 있습니다.

이 IPagedList는 것을 의미하지 않는다 모델, 그것은 단지뿐만 아니라 수 의 일부 모델 (그것의 속성). 이것이 매개 변수가없는 과부하가없는 이유 일 수 있습니다.

IPagedList를 오버로드로 추가 할 수는 있지만 실제 데이터 자체가 필요하지 않은 작은 호출기 도우미에 세트 (페이지가있는 데이터 청크)를 전달합니다. 페이지 수와 항목을 강조 표시 할 수 있도록 현재 페이지 / 항목 수와 현재 위치를 알아야합니다. 도우미에게 훨씬 더 많은 정보를 제공해야 할 것입니다. 작동 방식에 따라 커플 링이 낮으므로 좋은 것입니다.

클라이언트가 페이지 번호를 요구하고 클라이언트가 가장 다양 할 수있는 것은 페이지 크기입니다.

public ActionResult MostPopulars(int pageIndex,int pageSize)

이것을하는 꽤 합리적인 방법입니다. 나는 ennum (첫 번째, 다음, 이전, 마지막)이 사용되었지만 실제로는 "pageIndex"라고 말하는 어색한 변형을 보았습니다.

나는 페이지 크기가 매우 다양하고 다양해야한다는 것을 반복하고 싶다. 관련 뷰어에 따라 모바일, 휴대용 및 대형 스크린 워크 스테이션에 대해 서로 다른 기본값을 가져야하며, 많은 경우 최종 사용자가 얼마나 많은 항목을 구성하는지 선택하는 것이 합리적이다 페이지.

나는 이것이 MVC 프레임 워크 내에서 많은 매개 변수를 전달한다는 것을 알고 있지만 페이징의 전체 개념은 MVC를 깨뜨립니다. 페이징이 작동하기 위해서는 비즈니스 로직이 프레젠테이션에 대해 알아야하므로 항상 지저분 해집니다.