Postbacks ASP.NET x jQuery: Quels sont les inconvénients et les avantages?

Question

Je vais commencer quelques prototypes de laboratoire sur certaines de nos pages Web App. Nous utilisons beaucoup de Postback, ViewState, UpdatePanels, ModalPopup Extender, tous les trucs habituels d'ASP.NET. C'est assez bon pour la plupart des cas. Mais je veux pousser les choses plus loin ...

Je joue avec jQuery depuis un certain temps maintenant. Je sais ce qui est capable de. Je pense à substituer VRAIMENT les choses habituelles ASP.NET par des choses comme $.ajax(), $.get(), etc. Pas plus de publications. Interface utilisateur? interface utilisateur jQuery. Je suis vraiment impressionné par certains plugins, en particulier la grille jQuery. Je pense que c'est la prochaine étape dans l'interface utilisateur Web. Je veux dire, c'est DÉJÀ l'étape actuelle! J'aime la puissance de C#, mais je ne suis pas impressionné par le framework ASP.NET. J'imagine qu'en faisant cela, je vais vraiment séparer l'interface utilisateur de la logique métier.

Cependant:

• dois-je faire vraiment?
• Le code derrière doit-il être uniquement Web Handlers et Web Services?
• De quoi dois-je me méfier?
• Qu'en est-il de la sécurité? Comment l'implémenter?
• Que vais-je gagner? Je sais que je vais gagner en performance, car les publications sur des pages avec trop de données prennent du temps à cause de ViewState ET je ne traiterai que du XML et/ou du format JSON toujours léger. Mais j'imagine, comme d'habitude, qu'il y aura de la douleur ...
• Où sera la douleur?

Je vais ralentir, de toute façon. Mais je veux vous demander les gars: qu'est-ce que je suis en train de faire ici?

Answer 1

Avant de répondre, je vous suggère fortement d'opter pour ASP.NET MVC Framework. C'est un type de développement totalement différent de celui des Webforms. C'est un pas loin de ViewState et de cette ordure. C'est ici que Microsoft déploie tous ses efforts et c'est actuellement le seul moyen de construire des sites Web beaucoup plus évolutifs et interactifs sur le .NET Stack.

Dois-je vraiment le faire? Oui. jQuery + Ajax est très bon et vous permettra de créer des sites Web très interactifs et utilisables. Et la façon dont les choses se passent maintenant, la vérité à parler si vous n'utilisez pas la puissance de Javascript côté client, votre site Web voudrait construire en 1995.

Le code derrière être seulement Web Handlers et Services Web? Vous devez uniquement utiliser les gestionnaires/services pour améliorer la conception de votre page. Vous ne pouvez pas créer tout votre site Web uniquement à ce sujet. La méthode consiste à créer une page, puis à l'améliorer avec les services. Évitez les postbacks pour les petits détails. Et améliorer la vitesse par Ajax etc. Faire un site web entier sur Ajax n'est pas une bonne idée.

De quoi dois-je me méfier? Techniquement, vous devez comprendre le codage côté client et le fonctionnement de HTTP sur Internet. ASP.NET prend tout cela sous le capot, donc vous n'avez même pas besoin de savoir, mais si vous faites des postbacks, alors vous devriez comprendre ses limites, etc.

Que diriez-vous de la sécurité? Comment l'implémenter? Il n'y a pas beaucoup à la sécurité à Ajax aussi longtemps que vous faites la même chose que vous avez fait pour les attaques CSS de postbacks normales, les injections SQL, Anti-Contrefaçon, etc.

Que vais-je gagner? Je sais que je vais gagner en performance, car les publications sur des pages avec trop de données prennent du temps à cause de ViewState ET je ne traiterai que du XML et/ou du format JSON toujours léger. Mais j'imagine, comme d'habitude, qu'il y aura de la douleur ... Où sera la douleur? La douleur est habituellement la complexité. Mais la complexité vient avec la flexibilité. ASP.NET traditionnel prenait soin de tout sans que vous ayez à interférer. mais maintenant vous devez faire la demande, l'envoyer au serveur, recevoir la réponse, puis mettre à jour le DOM en conséquence. Vous devez faire face à tout cela, mais d'un autre côté, vous pouvez le gérer comme bon vous semble.

Espérons que ça aide.

Answer 2

Je dis oui. Les publications sont faciles pour le développeur et horribles pour l'utilisateur. Ne les faites pas souffrir de lourdes charges de pages juste pour basculer une case sur la page. Mais, vous devez tenir compte du temps que cela prendra, d'autant plus que vous pourriez avoir besoin de plus en plus de code javascript (ce qui peut être fastidieux si vous êtes nouveau).

Je l'ai récemment fait sur un grand projet et je suis content de l'avoir fait. Je suis passé des publications à pleine page aux WebMethods et aux services Web. Essayez de réduire l'état sur le serveur, ce qui aidera à compartimenter chaque gestionnaire de requêtes.

Answer 3

Regardez dans asp.net-MVC il est très probable de quoi vous parlez et implémente jquery et les appels JSON.

Answer 4

Si vous avez utilisé PostBack et ViewState, vous l'avez peut-être fait pour une raison. Cela permet les composants et les événements. C'est quelque chose que vous manquerez dans ASP.NET MVC (vous ne dites pas que vous voulez utiliser ASP.NET MVC, mais si vous dites ASP.NET sans PostBack tout le monde comprend ASP.NET MVC)

J'utilise ASP.NET et ASP.NET MVC. ASP.NET avec postback entre en jeu si le projet est vraiment plus une application qu'un site web (disons nyt.com étant un site web et facebook étant une application).