considérations pour choisir une approche d'application Web?

Question

Je suis un développeur d'applications Web Java de longue date, et, selon mon expérience, il existe deux approches principales pour la création d'applications Web.

La première approche consiste à utiliser des technologies qui vont et viennent du client au serveur comme Struts, SpringMVC, JSF et ainsi de suite. Le second est d'utiliser des technologies qui s'exécutent principalement sur le client comme Flex, Swing (démarrage Web), JavaFX et ainsi de suite. Je sais que ces deux approches vont rester ici pendant longtemps, et je sais que chacune a ses avantages et ses inconvénients.

J'aimerais vraiment savoir quand préférez-vous utiliser chacun d'entre eux? Que dois-je prendre en compte lorsque je choisis l'un plutôt que l'autre? Dites ce qui vous vient à l'esprit en termes de sécurité, de type d'application, de Stateless/Statefull, d'appels DB, ou de tout autre élément.

Il serait intéressant de voir quels sont les différents aspects.

Answer 1

Fondamentalement, la distinction est entre celle des clients «minces» et «gros».

Certains avantages et les inconvénients des deux

Fat client

• occasion de pousser plus logique de traitement au client, soulager les ressources du serveur. Cela peut également améliorer l'expérience utilisateur car l'interface graphique peut exécuter des tâches de mise à jour simultanément.
• plus facile pour le client de fonctionner hors ligne
• peut être plus facile à mettre en œuvre plus riche fonctionnalité GUI plus complexe
• , mais peut être plus difficile à la logique de réutilisation dans les différents types de clients (par exemple mobile de bureau &)
• MAIS Il peut être plus difficile à coder, nécessite des compétences plus spécialisées que le développement Web générique client/serveur, et signifie parfois qu'une plus grande partie de la logique de l'application est codée dans le client, ce qui réduit la séparation des préoccupations.
• MAIS souvent exclusif (par ex.flex)
• mais peut être plus difficile à exposer les données à crawlers web

Thin Client

• peut remettre de développement GUI à une équipe spécialisée distincte au code, alors que la logique métier est codé sur côté serveur par une autre équipe de spécialistes (bien que cela dépende beaucoup du type d'application et de la logique)
• Compétences de codage plus facilement disponibles (pour le client et le serveur)
• Favorise la réutilisation de la logique métier côté serveur à travers différents types graphiques ou API
• Les données peuvent facilement être exposés à des robots web
• MAIS Guis peut être souvent moins interactif aux frais de l'expérience utilisateur
• MAIS généralement ne peut pas fonctionner hors ligne

L'avènement de navigateurs plus puissants comme Chrome est cependant en train de brouiller la frontière entre les deux. D'une manière générale, je suppose que la solution par défaut serait toujours une solution client html, avec une logique métier sur le serveur, sauf si les exigences sont différentes (par exemple, besoins multimédias ou de traitement avancés ou choix d'interface utilisateur spécifiques). animations)

Answer 2

Mon conseil serait d'éviter les plugins dans tous les cas. N'utilisez pas les plugins Java, Flash ou Silverlight pour les applications Web. Vous vous préparez pour un monde de blessés sur la route. Si vous voulez construire un client riche, utilisez quelque chose qui génère du javascript. Si vous aimez Java, utilisez GWT. Si Java n'est pas votre tasse de thé, regardez les toolkits javascript, comme ExtJS, Dojo, Sproutcore.

La façon dont je vois les compromis:

client léger (HTML régulier):

• Upside: plus facile adapté à une variété de navigateurs et appareils
• Upside: pour une meilleure faible Downside: moins de richesse dans les contrôles de l'interface utilisateur
• Downside: les temps aller-retour vont tuer "flow". Si les utilisateurs doivent travailler pendant de longues périodes dans votre application, cette approche ne fonctionnera pas correctement.

client Rich (boîte à outils GWT ou JS):

• Upside: côté serveur peut mettre en œuvre juste une API propre
• Upside: conception de l'interface est plus facile à mettre en œuvre, plus riche
• Upside: vous pouvez planifier votre conception autour des temps d'aller-retour lents (avec "hors ligne" étant un cas extrême de temps d'aller-retour lent)
• Inconvénient: besoin d'un frontal séparé pour les appareils mobiles et les navigateurs de faible puissance
• Downside: faible bande passante fera le chargement si lent utilisateurs juste à pied

Pour mes applications, je tombe carrément dans le camp client riche. Mais je ne fais pas d'applications pour l'internet "public".