2009-08-25 9 views
14

Selon ma compréhension, les deux font essentiellement la même chose (nous permet d'exécuter une méthode côté serveur de JS). Y a-t-il des différences?Différence entre les rappels de client et les méthodes de page Ajax - ASP.NET

En outre, les méthodes de page Ajax peuvent être implémentées en utilisant JQuery ou en utilisant ScriptManager. Lequel est préféré et pourquoi ??

** BOUNTY: Ajout d'une prime pour obtenir une explication claire de la question. Merci **

Répondre

22

Fondamentalement, Client Callbacks et Ajax page Méthodes font la même chose. Ils utilisent un objet XMLHttpRequest pour envoyer une requête (généralement asynchrone) vers une URL, obtenir les résultats de cette requête, puis exécuter une méthode de rappel que vous avez fournie (callback avec en minuscule), en transmettant les résultats du demande à votre méthode.

Cela dit, il y a une grande différence entre les deux approches:

  • page Méthodes sont mises en œuvre en tant que méthodes statiques sur votre page. Votre classe de page est juste un conteneur pratique pour ces méthodes, qui pourraient vraiment être hébergés n'importe où (un service Web, un HttpHandler personnalisé, etc.). Comme aucune instance ne sera jamais construite, le client n'a pas besoin d'envoyer des données ViewState et Asp.Net n'a pas à parcourir le cycle de vie de Page. Le revers de la médaille est que vous n'avez pas accès aux méthodes et propriétés d'instance de votre classe Page. Cependant, dans de nombreux cas, vous pouvez contourner ce problème en refactorisant les méthodes d'instance en méthodes statiques. (Voir this article pour plus d'informations.

  • Les rappels de client sont implémentés en tant que méthodes d'instance sur votre page. Ils ont accès à d'autres méthodes d'instance sur votre page, y compris des éléments stockés dans ViewState. C'est pratique, mais cela a un prix: pour construire l'instance Page, le client doit envoyer une quantité relativement importante de données au serveur et doit parcourir une bonne partie du cycle de vie de la page. (. This article has a nice diagram montrant quelles parties)

En dehors de cela, le coût de leur mise en place varie assez peu et les clients les utilisent différemment:

  • client Callbacks nécessitent une bonne quantité de échafaudage idiosyncrasique code qui est intimement couplé à Asp.Net (comme indiqué dans le lien ci-dessus). Compte tenu des alternatives beaucoup plus faciles que nous avons maintenant, je suis tenté de dire que cette technologie est obsolète (pour de nouveaux développements).

  • méthodes de page d'appel à l'aide ScriptManager nécessite moins de configuration que le client Callbacks: il vous suffit à la pop un ScriptManager sur votre la page, définissez EnablePageMethods = true, ensuite accéder à vos méthodes de page par le proxy le proxy PageMethods.

  • Les méthodes de page d'appel utilisant jQuery requièrent seulement de lier la bibliothèque jQuery (et la connaissance de jQuery, bien sûr).

Je préfère utiliser jQuery pour accéder à des méthodes de page, car il est indépendant du cadre du serveur et expose juste la bonne quantité de détails de mise en œuvre, mais il est vraiment juste une question de goût. Si vous y allez avec ScriptManager, son proxy rend les appels de méthode de la page un peu plus faciles pour les yeux, ce que certains pourraient considérer comme plus important.

+0

Merci pour la réponse. Les méthodes de pagem peuvent-elles être non statiques? J'ai utilisé des rappels auparavant et il n'y avait aucune exigence pour qu'ils soient statiques. De cette façon, je pourrais avoir accès aux méthodes de la classe de base. Dans les méthodes de page, je ne peux pas. – Nick

+0

Mon plaisir! En ce qui concerne les méthodes de page, elles doivent être statiques car Asp.Net ne crée pas (et ne peut pas) créer des instances de votre classe Page lors de l'exécution d'une méthode de page. Cet article explique pourquoi (et pourquoi c'est généralement souhaitable): http://encosia.com/2008/04/16/why-do-aspnet-ajax-page-methods-have-to-be-static /. Cela dit, c'était un gros défaut de ne pas en parler dans ma réponse. Je mettrai à jour la réponse pour inclure cette information. –

+0

Je souhaite pouvoir doubler cette réponse. Merci Jeff! –

4

Je dirais qu'il y a des différences, mais je dirais plutôt que vous vous sentez plus à l'aise.

J'ai utilisé les deux approches, et avoir des appels jQuery de la page est généralement plus rapide. J'écris un gestionnaire ashx qui fait le travail dont l'appel jquery a besoin (interroger la base de données, traiter quelque chose, etc.) et l'appeler à partir de la page. Je n'utiliserais pas une page aspx pour un appel jQuery, car vous envoyez beaucoup d'informations dont vous n'avez pas besoin du tout. La différence/avantage d'utiliser un appel Ajax.Net est que vous n'avez pas besoin de construire une autre page pour traiter les choses, vous pouvez utiliser les mêmes événements de page pour le faire. Par exemple, si vous devez remplir une deuxième liste déroulante en utilisant la valeur sélectionnée sur un premier, vous pouvez utiliser Ajax.Net pour appeler le SelectedIndexChanged dans le code de la page et quand il se déclenche, allez Page_Load, SelectedIndexChanged, Page_PreRender et ainsi de suite. Dans la méthode événementielle, vous devez interroger le db et remplir le second ddl.

Avec jQuery, cela pourrait être un peu différent. Vous faites votre appel à un gestionnaire ashx, le gestionnaire est juste une méthode serveur qui fait la magie et renvoie les données sous la forme que vous voulez avoir (json, tableau de chaînes, xml, etc.) et remplit le deuxième ddl en utilisant javascript. Comme je vous l'ai déjà dit, certaines personnes ne se sentent pas trop à l'aise avec le code Client et ont tendance à le faire sur le serveur, mais je dis toujours que vous devez utiliser le bon outil pour le bon travail. appliquez-les à bon escient.

Si vous voulez en savoir plus sur ASP.Net, les gestionnaires ASHX et jQuery, vous pouvez lire un post que j'ai écrit à ce sujet.

espère qu'il helps.-

0

Ils sont essentiellement les mêmes. deux:

  1. Installation d'un webservice pour vous que le javascript pour le contrôle peut appeler.
  2. Fournir la réponse asynchrone e sans impliquer le cycle de vie de la page.

Ils sont différents:

  1. Méthodes Page exigent simplement que vous décorez une méthode statique avec un attribut et vous avez terminé. Le reste de la magie est géré par les gestionnaires et modules HTTP. Les rappels nécessitent l'implémentation de quelques interfaces et la gestion des gestionnaires d'événements asynchrones. Je les trouve un peu plus douloureux.
  2. Les rappels ne fonctionnent qu'avec certains contrôles. Les méthodes de page d'appel vous permettent d'affecter n'importe quel contrôle par le javascript personnalisé.Les rappels ont un léger avantage ici en ce que le comportement côté client est déjà écrit et corrigé. Avec les méthodes de page vous avez plus de flexibilité, cependant (le comportement du côté client est déterminé par vous).

Il existe quelques autres différences, mais ce sont les bases. Ma compréhension est que les callbacks des clients ont tendance à fonctionner aussi bien que les méthodes Page, mais ne sont pas utilisés autant parce qu'ils ne sont disponibles que dans certaines situations, alors qu'une Méthode de Page est toujours une avenue valide. En ce qui concerne la question ScriptManager ScriptManager vs JQuery, mon sentiment ici est qu'il est de goûter plus que tout. J'aime la syntaxe de JQuery et j'ai l'impression qu'elle fonctionne mieux, mais dans le grand ordre des choses, la chose la plus chère est le XmlHttpRequest ... après que l'exécution du javascript est susceptible d'être insignifiante en différence à côté de cela.

Questions connexes