6
votes

Je suis piégé dans le piège UpdatePanel

J'ai un très gros problème. Je fais un système de gestion de la relation CRM (Costurière) dans ASP.NET 3.5

J'ai basé mon projet entier sur les contrôles de DEVEXPress.com et l'utilisation des panneaux de mise à jour.

Maintenant une de mes pages, qui est une page centrale de l'ensemble du système, contient une très grande quantité de possibilités et donc une grande quantité d'usercontrols.

Maintenant, mon problème est que cela devient vraiment vraiment lent en raison du fait que les panneaux de mise à jour reposent sur la page entière et non seulement le panneau de mise à jour. Nous parlons de 3 à 4 secondes avant que la fenêtre contextuelle apparaisse: (

Y a-t-il un moyen de refroidir ce système entier loin des panneaux de mise à jour sans me casser le cou? Y a-t-il de toute façon que je puisse optimiser mon utilisation des panneaux de mise à jour?

Le spectacle est également absolument géant.

Toutes les bonnes idées sont les bienvenues ...


1 commentaires

Je suppose que ce que je demande aussi, y a-t-il un moyen de rendre un panneau Update Seulement rendre la nouvelle et non la page entière.


5 Réponses :


8
votes

Il n'y a aucun moyen de contourner la page entière en utilisant UpdatePanels. Au lieu de redéfinir l'application Voici quelques choses que j'essayais:

  1. désactiver la visualisation de la vue pour tout contrôle dont il n'en a pas besoin
  2. Définissez l'UpdateMode = "conditionnel" pour vos contrôles utilisateur. Cela ne se déplacera pas sur la publication de la page entière mais celle-ci réduira un peu de temps. Seul le contenu de l'accord de mise à jour spécifique sera mis à jour dans le navigateur.
  3. Assurez-vous que vos contrôles utilisateur ont des identifiants courts. La façon dont ASP.NET WebForms noms noms de noms dans le HTML Ces identifiants sont répétés un peu si vous avez beaucoup de contrôles de serveur. Ideme va pour nommer les installations de page principale. Une fois, j'ai coupé une grande page à la moitié de la taille en renommant les contrôles des utilisateurs et les espaces réservés.

4 commentaires

Lol je n'ai pas tenu compte de la question de nommer, bien que ce soit certainement là-bas .. Oui, ils se répètent beaucoup mais je déteste des noms courts non spécifiques ... maintenant je dois juste prendre en compte si je déteste lentement le chargement ralenti ..


Vous voudrez peut-être clarifier cela: "Seul le contrôle spécifique de l'utilisateur sera mis à jour à l'écran." Ce devrait probablement être "seulement l'accord de mise à jour spécifique ...". Vous voudrez peut-être également noter que seuls les panneaux nécessaires sont également envoyés au client, par opposition à la page entière.


+1 pour les identifiants courts. Il est très frustrant lors de l'optimisation de ma page pour réaliser la moitié de la demande de la demande d'élément ID: MasterPage_Page_Form_USeConfage_Page_Form_SeConTrol_GridView_ L'étiquette, etc., etc.


Sur le sujet de longs identifiants. Ne sont-ils pas compressés avant d'être envoyés sur le net?



0
votes

Vous devrez remplacer certains des post-retours contenus dans vos panneaux de mise à jour avec des appels AJAX réels, c'est-à-dire envoyer uniquement les données requises pour l'action sur le serveur et récupérer Seulement ce qui est nécessaire pour mettre à jour la vue, se débarrasser du potage et des pannes Update.

(vous remarquerez mon utilisation des termes «Action» et «View» - Oui, je suis un fan de MVC. La situation que vous êtes située est typique du gâchis qui se trouve facilement à l'aide de WebForms et de l'ASP. Contrôles NET AJAX.)


2 commentaires

Il est facile d'être un grand fan sur le nouveau gamin sur le bloc :) Je suis sûr qu'il est facile d'écrire un code désordonné dans l'un ou l'autre document.


Oui, c'est certainement possible. Le problème dans WebForms est qu'une page «Hello World» a déjà l'air désordonnée!



0
votes
  • Je dois manquer quelque chose. Pourquoi votre UpdatePomptez-vous est recharger la page entière. Le point d'un UpdatePanel est de rafraîchir ce qui est dans ce panneau, n'est-ce pas? Merci pour l'explication. Je suppose que nous parlons de republier la page et de ne pas redessiner le panneau comme je l'ai pensé.

  • Essayez d'éteindre la visiteuse de la vue, en particulier pour les grilles.

  • Quel type de contrôle est le plus courant sur votre page? Essayez de remplacer ceux-ci avec votre propre commande USERControl légère ou de serveur qui n'utilise pas ViewState ou ControlState

2 commentaires

UpdatePanels Ne rafraîchissez que le contenu à l'intérieur du panneau, mais l'ensemble du cycle de vie de la page est exécuté - ce qui signifie que la visionnement de toutes les commandes est envoyée sur / depuis le serveur.


Merci pour l'explication. Donc, c'est vraiment un problème d'opinion. Viewstate / ControlState sont des bugs :) Je les désactive chaque fois que possible.



2
votes

Puisque vous êtes un utilisateur de DevExpress, vous pourriez envisager de prendre un peu de temps pour apprendre leur CallbackPanel qui vous permettra de faire un traitement asynchrone sans les frais généraux de l'emballage Update.

Alternativement (quelqu'un s'il vous plaît corrigez-moi si je me trompe), mais si tous des post-colbacks sont asynchrones (c'est-à-dire dans un Panneau de mise à jour), ne serait-il pas théoriquement possible de désactiver la vision de la vieille page (dans la directive page) sans conséquences négatives? Vous devrez le tester complètement bien sûr, mais ça vaut la peine d'être coupé.


0 commentaires

0
votes

Pour tous les intéressés, je veux ajouter une solution sur la manière de vous débarrasser des données de visualisation sur Clientside. Il donne au serveur une charge supplémentaire, mais si vous êtes dans la même situation que moi et que vous avez beaucoup de puissance du serveur et que vous devez prendre la charge des clients, c'est bien.

Toutes vos pages dérivent de basepage.cs ressemblant à ceci xxx

Vous avez maintenant une clé de la session de données d'opinion au lieu de la visualisation de votre code ...

fonctionne comme un charme Moi sur un site Web avec 1000-1200 visiteurs quotidiens également.


0 commentaires