Côté Client, la logique OU logique côté Serveur?

Question

J'ai fait quelques projets web, et la plupart des difficultés que j'ai rencontré (les questions, les confusions) peut être trouvé avec de l'aide. Mais j'ai encore une question importante, même après avoir posé des développeurs expérimentés: Lorsque la fonctionnalité peut être mis en œuvre à la fois avec le code côté serveur et côté client de script (JavaScript), dont l'une doit être préféré?

Un exemple simple:

Pour effectuer le rendu d'une page html dynamique, je peux le format de la page dans le code côté serveur (PHP, python) et l'utilisation d'Ajax pour récupérer la page mise en forme et de les rendre directement (plus logique sur le serveur-côté, moins sur le côté client).

Je peux aussi utiliser de l'Ajax pour récupérer les données (non formaté, JSON) et utiliser un script côté client pour le format de la page et la rendre avec plus de traitement (le serveur reçoit les données à partir d'une base ou d'une autre source, et la renvoie au client avec JSON ou XML. De plus logique sur le côté client et moins sur le serveur).

Alors, comment puis-je décider lequel est le mieux? Ce qui une offre de meilleures performances? Pourquoi? Lequel est le plus facile à utiliser?

Je me demandais, avec des navigateurs JS moteurs de l'évolution, JS peut être interprété en moins de temps. Dois-je donc préfèrent les scripts côté client?

Je me demande aussi, avec le matériel évolue, les performances du serveur augmentera le coût sera de diminuer, donc si je préfère de script côté serveur?

EDIT:

Avec les réponses, je veux donner un bref résumé.

Les Pros du côté client:

1. meilleure expérience utilisateur
2. économiser de la bande passante du réseau (diminution des coûts)
3. évolutivité (boom de PVs, la croissance n'augmente pas autant que le côté serveur logique)

Les Pros du côté serveur:

1. les questions de sécurité
2. amélioration de la disponibilité et de l'accessibilité (appareil mobile, les anciens navigateurs, SEO)
3. développez facilement(on peut ajouter d'autres serveurs, mais nous ne pouvons pas rendre le navigateur plus rapide)

Il semble que nous avons besoin d'un équilibre entre ces deux approches face à un scénario spécifique. Mais comment? Quelle est la meilleure pratique?

IMO, je vais utiliser côté client, la logique à l'exception des conditions suivantes:

1. de sécurité critique
2. des groupes spéciaux (désactivé JavaScript, des appareils mobiles, et autres)

Answer 1

Dans de nombreux cas, j'ai peur que la meilleure réponse est les deux.

Comme Ricebowl dit, ne faites jamais confiance le client. Cependant, j'ai l'impression que c'est presque toujours un problème si vous faites confiance au client. Si votre demande est en valeur l'écriture, il est intéressant de sécurité. Si quelqu'un peut le briser par la rédaction de leurs propres clients et de la transmission des données, vous ne vous attendez pas, c'est une mauvaise chose. Pour cette raison, vous devez le valider sur le serveur.

Malheureusement, si vous validez le tout sur le serveur, qui souvent laisse à l'utilisateur une expérience utilisateur médiocre. Ils peuvent remplir un formulaire seulement pour trouver qu'un certain nombre de choses qu'ils ont saisies sont incorrectes. Cela peut avoir travaillé pour "Internet 1.0", mais les attentes sont plus élevées sur l'Internet aujourd'hui.

Ce qui vous laisse écrire un peu de code redondant, et en la maintenant dans deux endroits ou plus (certaines des définitions telles que les longueurs maximales doivent également être maintenus dans la couche de données). Raisonnablement penser que de grandes applications, j'ai tendance à résoudre ce problème à l'aide de la génération de code. Personnellement, j'utilise un outil de modélisation UML (Sparx du Système Enterprise Architect) pour le modèle d'entrée "règles" du système, puis faire usage de classes partielles (d'habitude je suis en train de travailler .NET) pour générer le code de validation de la logique. Vous pouvez obtenir quelque chose de similaire par le codage de vos règles au format XML et d'en déduire un certain nombre de chèques à partir de ce fichier XML (entrée longueur, le masque de saisie, etc.) sur le client et le serveur de niveau.

Probablement pas ce que tu voulais entendre, mais si vous voulez le faire correctement, vous devez appliquer les règles sur les deux niveaux.

Answer 2

J'ai tendance à préférer une logique côté serveur. Mes raisons sont assez simples:

1. Je n'ai pas confiance du client, ce qui peut être ou ne pas être un vrai problème, mais il est habituel
2. Côté serveur permet de réduire le volume par transaction (bien qu'il ne l'augmentation du nombre de transactions)
3. Côté serveur signifie que je peux être à peu près sûr de ce que la logique est de prendre la place (je n'ai pas à vous soucier de le moteur Javascript disponible pour le navigateur du client)

Il y a probablement plus -et mieux - raisons, mais ce sont ceux du haut de mon esprit en ce moment. Si je pense de plus je vais les ajouter, ou de voter ceux qui viennent avec eux avant que je ne.

---

Édité, valya commentaires que l'utilisation de logique client (à l'aide d'Ajax/JSON) permet l' (plus facile) la création d'une API. C'est peut-être vrai, mais je peux seulement à moitié d'accord (c'est pourquoi je n'ai pas voté pour que encore de réponse).

Ma notion de logique côté serveur est à celui qui récupère les données, et organise des il; si j'ai ce droit, la logique est le "contrôleur" (C MVC). Et c'est ensuite transmis à la " vue.' J'ai tendance à utiliser le contrôleur pour obtenir les données, puis l'onglet "affichage" traite de la présenter à l'utilisateur/client. Donc je ne vois pas ce client/serveur, des distinctions sont nécessairement à l'argument de la création d'une API, en gros: des chevaux pour les cours. :)

...aussi, comme un amateur, je reconnais que j'ai peut-être un peu tordu utilisation de MVC, donc je suis disposé à être corrigé sur ce point. Mais je garde toujours la présentation séparée de la logique. Et que la séparation est le point plus loin que les Api aller.

Answer 3

J'ai généralement de mettre en œuvre autant que raisonnable côté client. Les seules exceptions qui me ferait aller côté serveur serait de résoudre le suivant:

Les problèmes de confiance

N'importe qui est capable de débogage JavaScript et de la lecture du mot de passe, etc. Évidence ici.

Les problèmes de performances

Les moteurs JavaScript sont en évolution rapide, donc ce n'est plus un problème, mais nous sommes encore dans un IE-dominé monde, donc les choses vont ralentir lorsque vous traitez avec de grands ensembles de données.

Les problèmes de langue

JavaScript est faiblement typé langue et il fait beaucoup d'hypothèses de votre code. Cela peut vous amener à employer spooky solutions de contournement afin d'obtenir les choses de fonctionner comme il faut sur certains navigateurs. - Je éviter ce genre de chose comme de la peste.

---

À partir de votre question, il semble que vous essayez simplement de charger des valeurs dans un formulaire. En l'absence de toute les questions ci-dessus, vous avez 3 options:

Pure côté client

L'inconvénient est que vos utilisateurs le temps de chargement double (une charge pour la forme vide, une autre charge pour les données). Cependant, les mises à jour ultérieures de la forme n'aurait pas besoin d'un rafraîchissement de la page. Les utilisateurs de ce genre si il y aura beaucoup de récupération de données à partir du serveur de chargement dans le même formulaire.

Pure côté serveur

L'avantage est que votre page serait de charger les données. Cependant, à la suite des mises à jour des données nécessiteraient actualise à toutes les/que de grandes parties de la page.

Client-serveur hybride

Vous aurez le meilleur des deux mondes, cependant vous avez besoin pour créer des données de deux points d'extraction, à l'origine de votre code d'enfler légèrement.

Il existe des échanges avec chaque option de sorte que vous aurez à peser le pour et de décider ce que vous offre le plus d'avantages.

Answer 4

D'un examen, je n'ai pas entendu parlé, c'était la bande passante du réseau. Pour donner un exemple concret, une application, j'ai participé à été fait côté serveur et a abouti à 200 mo page web d'être envoyé au client (il était impossible de faire moins sans majeur majeur de la re-conception d'un tas d'applications); résultant de 2-5 minutes de temps de chargement de page.

Lorsque nous nous sommes mis en œuvre en envoyant le JSON données codées à partir du serveur et local JS génération de la page, le principal avantage est que les données envoyées réduit à 20 mo, ce qui entraîne:

• De la réponse HTTP taille: 200 mo+ => 20 mo+ (correspondant aux économies de bande passante!)

• De temps à charger la page: 2-5 minutes => 20 secondes (10 à 15 qui sont prises par DB requête qui a été optimisé pour l'enfer un plus).

• IE processus de taille: 200 MO+ => 80 MO+

Rappelez-vous, les 2 derniers points sont principalement dues au fait que côté serveur eu à utiliser de merde tableaux dans les tableaux de l'arbre de la mise en œuvre, alors que d'aller à côté client nous a permis de refonte de la couche de la vue à utiliser beaucoup plus léger, page. Mais mon point principal était la bande passante du réseau de l'épargne.

Answer 5

J'ai construit une bonne application web où toutes les fonctionnalités CRUD sont disponibles en l'absence de JavaScript, en d'autres termes, tous AJAX effets sont strictement progressive des améliorations.

Je crois qu'avec assez de dévouement, la plupart des applications web peuvent être conçues de cette manière, d'où un affaiblissement de nombreux de la logique du serveur vs client de la logique de "différences", tels que la sécurité, l'évolutivité, soulevé dans votre question, parce que dans les deux cas, la demande est acheminée à un même contrôleur, dont la logique métier est tout de même jusqu'à ce que le dernier kilomètre, où JSON/XML, au lieu de la pleine page HTML, est renvoyé pour ceux XHR.

Seulement dans quelques cas où la AJAXified application est bien plus avancée que ses statique contrepartie, GMail étant le meilleur exemple de venir à mon esprit, alors on a besoin de créer deux versions et de les séparer complètement (Bravo à Google!).