2009-06-30 13 views
6

Mam bardzo duży problem. Tworzę system CRM (Costumer Relationship Management) w ASP.NET 3.5Jestem uwięziony w pułapce UpdatePanel

Oparłem cały mój projekt na kontrolkach DevExpress.com i korzystaniu z UpdatePanels.

Teraz jedna z moich stron, która jest centralną stroną całego systemu, zawiera bardzo dużą liczbę możliwości, a zatem dużą liczbę UserControls.

Teraz mój problem polega na tym, że robi się naprawdę bardzo wolny ze względu na fakt, że UpdatePanels przerywają całą stronę, a nie tylko panel aktualizacji. Mówimy czasami wykonać 3-4 sekund zanim pojawi się okienko :(

Czy jest jakiś sposób mogę byłaby cały ten system od UpdatePanels nie łamiąc sobie kark? Czy mimo to mogę zoptymalizować wykorzystanie UpdatePanels?

elementu ViewState jest również absolutnie gigantyczny.

Wszelkie dobre pomysły są mile widziane ...

+0

Zgaduję, o co też pytam, czy istnieje sposób na to, aby UpdatePanel renderował TYLKO nową, a nie całą stronę. –

Odpowiedz

8

nie ma sposobu, aby ominąć księgowania całą stronę używając UpdatePanels. zamiast przebudowy aplikację oto kilka rzeczy Spróbowałbym:

  1. Wyłącz viewstate dla jakiejkolwiek kontroli, że nie trzeba go
  2. Ustaw UpdateMode = „warunkowy” dla formantów użytkownika. Nie spowoduje to opublikowania całej strony, ale zmniejszy nieco czas renderowania. Tylko zawartość dla określonego UpdatePanel będzie aktualizowana w przeglądarce.
  3. Upewnij się, że formanty użytkownika mają krótkie identyfikatory. Sposób, w jaki webformy ASP.NET nazywa kontrolki w html, te identyfikatory są powtarzane całkiem sporo, jeśli masz dużo kontroli serwera. To samo dotyczy nazywania zastępczych stron wzorcowych. Raz wyciąłem dużą stronę na połowę, zmieniając nazwy elementów sterujących i symboli zastępczych.
+0

LOL Nie brałem pod uwagę problemu z nazywaniem, chociaż jest on zdecydowanie na miejscu ... tak, oni często się powtarzają, ale nienawidzę krótkich nieokreślonych nazw ... teraz muszę tylko zastanowić się, czy nienawidzę powolnego ładowania jeszcze więcej ... –

+0

Możesz to wyjaśnić: "Tylko konkretna kontrola użytkownika zostanie zaktualizowana na ekranie." Prawdopodobnie powinien to być "Tylko konkretny UpdatePanel ...". Możesz również zauważyć, że tylko niezbędne panele są wysyłane również do klienta, w przeciwieństwie do całej strony. –

+0

+1 za krótkie identyfikatory. To bardzo frustrujące, gdy optymalizuję moją stronę, aby zdać sobie sprawę, że połowa złożonego żądania to element ID: masterpage_page_form_usercontrol_nestedusercontrol_gridview_label etc etc ... –

0

Będziesz musiał zastąpić niektóre postbacks zawartych w swoich panelach aktualizacja z rzeczywistym wywołania Ajax, czyli wysłać tylko dane, które są niezbędne do działania do serwera i wrócić tylko co jest wymagane aby zaktualizować widok, pozbywając się odświeżania i UpdatePanels.

(Zauważysz, że używam terminów "akcja" i "widok" - tak, jestem fanem MVC. Sytuacja, w której się znajdujesz jest typowa dla bałaganu, który łatwo wpada w użycie WebForms i ASP Kontrolki .NET AJAX.)

+0

Łatwo być wielkim fanem nowego dziecka w bloku :) Jestem pewien, że łatwo jest napisać niechlujny kod w obu frameworkach. – kervin

+0

Tak, to zdecydowanie możliwe. Problem w WebForms polega na tym, że strona "Hello World" wygląda już niechlujnie! –

0
  • Muszę czegoś brakować. Dlaczego twój updatepanel przeładowuje całą stronę. Punktem aktualizacji jest odświeżenie tylko tego, co jest w tym panelu, prawda? Dzięki za wyjaśnienie. Sądzę, że mówimy o przerzucaniu strony i nie przerysowywania panelu, tak jak myślałem.

  • Spróbuj wyłączyć ViewState, szczególnie w przypadku sieci.

  • Jakiego rodzaju kontrola jest najczęstsza na twojej stronie?Spróbuj wymienić te z własnego lekkiego UserControl lub Control Server, który nie korzysta z ViewState lub controlState
+1

UpdatePanels odświeża tylko zawartość wewnątrz panelu, ale cały cykl życia strony zostaje wykonany - co oznacza, że ​​stan wyświetlania wszystkich kontrolek jest wysyłany do/z serwera. –

+0

Dzięki za wyjaśnienie. Tak naprawdę jest to problem z ViewState. ViewState/ControlState to błędy :) Wyłączam je, gdy tylko jest to możliwe. – kervin

2

Ponieważ jesteś użytkownikiem DevExpress, można rozważyć biorąc trochę czasu, aby nauczyć ich CallbackPanel który pozwoli Ci zrobić asynchroniczny przetwarzanie bez obciążenia UpdatePanel.

Alternatywnie (ktoś proszę mnie poprawić, jeśli się mylę), ale jeśli wszystko z postbacks są asynchroniczne (tj w UpdatePanel), nie byłoby teoretycznie możliwe, aby wyłączyć ViewState dla całej strony (w Strona dyrektywy) bez negatywnych konsekwencji? Musiałbyś to sprawdzić całkowicie poza kursem, ale warto spróbować.

+0

Dam to spróbować, najlepsza sugestia do tej pory .. –

0

Dla wszystkich zainteresowanych chcę dodać rozwiązanie, w jaki sposób pozbyć się danych Viewstate na kliencie. Daje to serwerowi dodatkowe obciążenie, ale jeśli jesteś w takiej samej sytuacji jak ja i masz dużo mocy serwera i musisz wziąć na siebie obciążenie klienta to jest miłe.

Niech wszystkich stron wynikają z BasePage.cs patrząc jak ten

public class BasePage : System.Web.UI.Page 
{ 
    protected override void SavePageStateToPersistenceMedium(object viewState) 
    { 
     string vsKey = String.Format("VIEWSTATE_{0}_{1}_{2}", base.Session.SessionID, Request.RawUrl, DateTime.Now); 
     Session.Add(vsKey, viewState); 
     ClientScript.RegisterHiddenField("__VIEWSTATE_KEY", vsKey); 
    } 

    protected override object LoadPageStateFromPersistenceMedium() 
    { 
     string vsKey = Request.Form["__VIEWSTATE_KEY"]; 
     return Session[vsKey]; 
    } 
} 

Teraz masz klucz do sesji danych viewstate zamiast stanu wyświetlania w kodzie ...

działa jak urok dla mnie na stronie internetowej z 1000-1200 codziennie odwiedzających.

Powiązane problemy