Quels sont les avantages de scriptmanager par rapport aux appels jquery ajax directs?

Question

Je suis un peu confus au sujet des avantages ou du conc en utilisant scriptmanager avec des appels ajax ou en utilisant JQuery pour diriger des méthodes web d'appel. Est-ce que quelqu'un peut me donner quelques indications à propos de ce problème? quand utiliser quoi? il y a tout différent en traitant avec JSON?

Answer 1

Je pense que le MSDN ScriptManager control page ne fait un bon travail de résumer les caractéristiques -

• script registre qui est compatible avec les mises à jour de pages partielles.

• Afin de gérer les dépendances entre votre script et la bibliothèque centrale , tout script que vous enregistrez est chargé après le script Microsoft AJAX Library .

• Indiquez si les scripts de version ou de débogage sont envoyés au navigateur.

• Fournissez un accès aux méthodes de service Web à partir du script en enregistrant les services Web avec le contrôle ScriptManager .

• Fournir un accès à l'authentification ASP.NET, le rôle et le profil services d'application de script client en vous inscrivant ces services avec le contrôle ScriptManager.

• Activer l'affichage spécifique à la culture de ECMAScript (JavaScript) Date, Nombre et fonctions de chaîne dans le navigateur .

• ressources de localisation d'accès pour les fichiers de script intégré ou pour fichiers de script autonomes en utilisant la propriété de ResourceUICultures du contrôle ScriptReference .

• contrôles serveur registre qui mettent en œuvre la IExtenderControl ou interfaces IScriptControl avec le contrôle ScriptManager de telle sorte que le script requis par les composants client et comportements est rendu.

Essentiellement ScriptManager fait ce qu'il dit, gère vos scripts sans trop se soucier de votre part avec l'écriture du code JavaScript « colle » pour le faire vous-même. Bien sûr, il y a (peut-être significatif) une surcharge pour inclure le contrôle ScriptManager, notamment le nombre de requêtes supplémentaires pour les ressources de script et la taille des classes proxy générées pour appeler les services web et les méthodes page. Cela peut ne pas être si important lors du développement d'une application intranet où la bande passante et la vitesse du réseau sont susceptibles de poser moins de problèmes que le développement d'une application pour Internet, mais il est néanmoins important d'en être conscient. Si vous êtes à l'aise avec une bibliothèque JavaScript capable de remplacer toutes les fonctionnalités de ScriptManager tout en étant plus légère et plus rapide, cela semble être un bon cas pour ne pas utiliser ScriptManager.

En termes de traitement de JSON, jQuery et ScriptManager le gèrent correctement. IIRC, JSON est le type de données par défaut pour les méthodes de page et les services Web dans .NET (bien que quelque chose me rappelle que ce n'était pas toujours le cas).

Answer 2

Appels WRT Ajax? Très peu. Très très peu. Il y a quelques possible avantages pour le framework ASP.NET AJAX sur jQuery:

1. Syntaxe. Le cadre vous permet de faire vos appels WebService ressemblent vraiment vous appelez une méthode locale et transmettant les paramètres:

   MyNamespace.MyWebservice.MyMethod('arg1value', 'arg2value', onResult); 
   

   Remarquez que la version du framework connaît l'ordre des paramètres à la méthode de service Web.

   jQuery's .ajax nécessite que la plomberie soit configurée pour appeler une méthode de service Web ASP.NET AJAX. Il est minime et blogué sur fairly. well:

   $.ajax({ 
       type: "GET", 
       url: "MyWebservice.asmx/MyMethod", 
       data: '{"arg1":"arg1value","arg2":"arg2value"}', 
       contentType: "application/json; charset=utf-8", 
       dataType: "json", 
       success: function(data) { 
       onResult(data.d) // ASP.NET returns payload in `".d"` property 
       } 
   }); 
   

2. JSON sérialisation pour passer args au service Web: ASP.NET Framework Ajax a Sys.Serialization.JavaScriptSerializer.serialize qui fait le travail de sérialisation vos paramètres de service Web "dans les coulisses". Avec seulement jQuery pourrait devoir inclure une troisième bibliothèque, par exemple JSON.stringify de json.org. C'est tellement négligeable que d'être discutable.

3. Hardcoding Types de requêtes GET et POST. Étant donné que le framework génère pour vous un proxy client JavaScript à partir de la définition de classe WebService, vous ne savez généralement pas (ou ne vous souciez pas) de la méthode de requête HTTP dans le client. Vous venez de le définir dans l'attribut ScriptMethod de votre classe de service Web et de l'appeler depuis le client. Avec jQuery vous devez le connaître pour le passer à .ajax comme l'option type.

En ce qui concerne les avantages non-WRT choses Ajax, @Russ Cam les a résumées déjà pour toi.

---

_{déjà intégré à FF 3.1 et IE8}