Mevcut sayfalama uygulamalarının tasarımı hakkında soru


12

Özellikle asp.net mvc üzerinde sayfalama uygulamalarını kontrol ettim ve gerçekten uygulamalarda daha az verimli bir şey olduğunu hissediyorum.

Her şeyden önce, aşağıdaki gibi sayfalandırma değerlerini kullanır.

public ActionResult MostPopulars(int pageIndex,int pageSize)
{

}

Yanlış hissediyorum şey pageIndex ve pageSize tamamen Pagination sınıfının üyesi olmalıdır aksi takdirde bu şekilde çok fonksiyonel bir şekilde görünüyor. Ayrıca uygulama katmanlarında gereksiz parametre geçişini kolaylaştırır.

İkinci şey, aşağıdaki arayüzü kullanmalarıdır.

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

Benim sayfalandırma farklı eylem yönlendirmek istiyorsanız, bu yüzden içinde kapsül adı ve hatta denetleyici adı için yeni görünüm modeli oluşturmak zorunda. Başka bir çözüm daha sonra görüntülemek için parametre olarak çağrı cihazı yönteminde kodlanmış eylem ve denetleyici sabit belirtmek için bu arabirim modeli gönderme olabilir ama kesinlikle sadece bir eyleme bağlıdır çünkü benim görüş tamamen yeniden kullanılabilirliğini kaybediyor olabilir.

Başka bir şey, aşağıdaki kod görünümünde kullandıkları

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

Model IPagedList ise neden böyle bir aşırı yük yöntemi sağlamazlar @Html.Pager(Model)veya daha iyi bir yöntemdir @Html.Pager(). Model tipini bu şekilde bildiğimizi biliyorsunuz. Önce Model.PageNumber yerine Model.PageIndex kullanıyordum çünkü hata yapıyordu.

Bir başka büyük sorun da, IQueryable arayüzüne güçlü bir şekilde güvenmeleri. Veri katmanımda IQueryable kullandığımı nereden biliyorlar? Ben sadece sayfalama uygulama kalıcılığını cahil tutmak koleksiyonları ile çalışmak beklenebilir.

Sayfalandırma uygulamaları hakkındaki iyileştirme fikirlerimin yanlış olan tarafı nedir? Sayfalarını bu şekilde uygulamamalarının nedeni nedir?


Benim için oldukça karmaşık görünüyor. Sorunun tam olarak ne olduğunu tam olarak anladığımdan değil, ama ... gerçekten yerleşik yardımcıları kullanmanız gerekiyor mu? Çağrı cihazı bulunduğunu bile bilmiyordum. İlk (ve başarısız) yerleşik yardımcılarla geçinmeye çalıştıktan sonra MVC 1 Beta günlerinden beri kendi yardımcılarımın bir koleksiyonunu geliştirdim. Size de aynısını öneriyorum. Bu yardımcılarla mücadele ediyorsanız, sunucu denetimleriyle mücadele ettiğiniz WebForms'tan daha iyi değildir.

ASP.NET MVC yerleşik sayfalandırma yardımcıları sadece üçüncü taraf sayfalandırma uygulamaları vardır.
Freshblood

Biraz bilgi için teşekkürler. Soru şu: Neden bir taneye ihtiyacınız var? Tıpkı olmasını istediğiniz gibi kendi başınıza uygulamak için hiçbir çaba yok.

Sadece fikirlerimde bir sorun olduğunu bilmek istedim. Bazı temel ilkeleri
kırdım

Bir kod bir programcının sorununu çözemezse, kodun değeri yoktur, onu kullanmamanız daha iyi olur.
Shaheer

Yanıtlar:


1

User8685'in belirttiği gibi: arayüzünüz mevcut MVC materyallerine ve ilkelerine gereksiz görünüyor.

Bunu deneyin: IPagedList'ten ihtiyaç duyduğunuz, sayfa dizini vb. Gibi bilgiler iş mantığı katmanında uygulanmalı ve sunucuya geri beslenip güvenli bir şekilde yayınlanıp işlenebilecek genel bir model aracılığıyla görünüme / sayfaya aktarılmalıdır. Neden? Çünkü burada açıkça topladığınız şey, bilgi sisteminize bir girdidir ve bu nedenle kullanıcı arayüzünden daha düşük katmanlara aittir.

Bu yol gitmek için en iyi yol olmayabilir ve kesinlikle en hızlı değildir, ancak soyutlama ve veri mimarisi açısından gerçekten neye ihtiyacınız olduğunu görmenizi kolaylaştırır ve böylece artıklığı kaldırmanıza yardımcı olur.

Ayrıca, mevcut yardımcılar genellikle basit kullanım için çok fazla ek yük içerir ve bazen büyük resmi gizler.


0

Bu IPagedList veya yardımcı şey kullanmadım ama bu benim almak:

MostPopular(int pageIndex,int pageSize)Belirten açık bir arayüz: Sadece dönecektir sayfaları mostpopular şeylerden. Bana hangi sayfanın ve boyutunun olduğunu açıkça söylüyorsun.

Bir kontrolör yöntemi yapmışlarsa MostPopular(IPagedList<T> page)arayüz daha kafa karıştırıcı hale gelir. Kontrolöre toplam öğe miktarını mı söylüyorsunuz?

Denetleyici, belirli sayfalanmış veri diliminizi aldığında, toplamda kaç öğe olduğu gibi diğer çeşitli verileri de bulabilir. Bu noktada, bu verileri bir görünüme döndürmek mantıklıdır, böylece bazılarını seçici olarak kullanabilir.

Bu IPagedList olduğu anlamına gelmez modeli, böylesi daha iyi olabilir parçası bir model (Üzerinde mülkiyet). Bu yüzden parametresiz aşırı yük yoktur.

IPagedList'i aşırı yük olarak ekleyebilirlerdi, ancak gerçek verilerin kendisine ihtiyaç duymayan küçük bir çağrı cihazına bir kümeyi (disk belleği olan bir veri kümesi) geçirirsiniz. Şu anda kaç sayfa / öğe olduğunu ve şu anda nerede olduğunuzu bilmesi gerekir, böylece sayfa numarasını ve benzerlerini vurgulayabilir. Yardımcıya, işini yapması gerektiğini bilmesinden çok daha fazlasını söylerdiniz. Şimdi çalışma şekli daha düşük bağlantıya sahip, bu iyi bir şey.


Ben sadece eylem yöntemi parametresi PageIndex ve PageSize adlı bir özelliği olan bir nesne olabileceğini söylemek istedim, böylece birileri sunucu performansını saldırmak için büyük miktarda sayfa boyutu itebilir çünkü bu şekilde modeli kolayca doğrulayabiliriz. Ve parametresiz aşırı yük sağlarlarsa, model IPagedList olduğunda parametresiz aşırı yük kullanılabilir olur. Ben yardımcı ihtiyaçları sonra daha fazla veri geçiyorsanız yanlış bir şey yok. En iyi uygulama gibi katı bir kural yoktur.
Freshblood

0

İstemcinin bir sayfa numarası istediği ve istemcinin değişme olasılığının en yüksek olduğunu düşündüğüm sayfa boyutu:

public ActionResult MostPopulars(int pageIndex,int pageSize)

Bunu yapmanın oldukça mantıklı bir yoludur. Bir ennumun (ilk, sonraki, önceki, son) kullanıldığı varyasyonları gördüm ama gerçekten "pageIndex" demenin garip bir yolu.

Sayfa boyutunun çok değişeceğini ve çok değişmesi gerektiğini tekrar ediyorum, ilgili görüntüleyiciye bağlı olarak cep telefonları, taşınabilir cihazlar ve büyük ekran iş istasyonları için farklı varsayılanlar almalısınız, ayrıca çoğu durumda son kullanıcının kaç öğeyi oluşturduğunu seçmesine izin vermek mantıklıdır Bir sayfa.

Bu bir MVC çerçevesi içinde geçen bir sürü parametre ile sonuçlandığını biliyorum, ancak tüm sayfalama kavramı MVC'yi kırıyor - iş mantığınızın, sayfalamanın çalışması için sunum hakkında bilgi sahibi olması gerekiyor, böylece her zaman dağınık olacak.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.