La logique métier appartient-elle vraiment au serveur?


10

Une pile typique pour une application Web est une base de données, un serveur avec du code côté serveur et un utilisateur avec un navigateur avec HTML / CSS / JavaScript.

Avant AJAX étendu, MVC dans lequel le contrôleur était le code côté serveur déchiré. Un serveur devait acheminer les demandes de réponse pour les pages Web dynamiques (c'est-à-dire des solutions html basées sur des modèles comme JSP et ASP). Le serveur pour coordonner les appels vers la base de données et décider quelle page dynamique utiliser pour répondre à la demande de page. Le résultat de tout cela est que le serveur a fini par contenir la logique métier, même si la logique métier n'est pas fortement liée à l'idée de servir des pages.

Maintenant que nous passons au "Web 2.0", un serveur héberge des pages statiques qui utilisent JavaScript pour se remplir et changer ce qu'elles présentent. Le peut être dans le JavaScript. Le JavaScript implémente souvent un service RESTful, ce qui signifie qu'il spécifie une requête de base de données.

Le serveur est donc laissé aux rôles de servir des fichiers réels et de répondre aux appels AJAX. Et répondre aux appels AJAX est simplement une gestion de session et une sécurité. Et vraiment, ce qu'un utilisateur devrait même pouvoir voir, ce sont des données qui devraient être spécifiées dans la base de données.

Donc, à partir de là, le serveur devrait-il être relégué au rôle d'intermédiaire stupide qui ne fait qu'occasionnellement quelque chose comme envoyer un e-mail ou déclencher un service Web? La logique métier pourrait-elle tous vivre en JavaScript (quand ce n'est pas secret) ou vivre dans des procédures stockées quand c'est le cas?

Sera-t-il logique de peut-être même combiner serveurs et bases de données ou faire fonctionner des solutions ERP comme SAP comme serveurs?

Réponses:


14

La logique métier doit presque toujours s'exécuter sur un serveur que vous contrôlez, pour des raisons de sécurité. Si par "serveur" vous voulez dire "serveur web", alors je suis d'accord, il n'a pas besoin d'avoir presque n'importe quelle logique métier. Mais vous avez presque toujours besoin d'un serveur d'applications avec la logique métier, que ce soit à l'intérieur d'une base de données ou d'un serveur Web ou qu'il soit séparé et appelé par le serveur Web.

Il existe des applications réelles où le serveur Web ne fait rien d'autre que d'exposer l'API du serveur d'applications via des services Web ou JSON.

Même avant le Web 2.0 et AJAX, il n'était vraiment pas considéré comme une meilleure pratique pour mélanger votre logique métier avec des pages ASP. Il a été jugé préférable d'avoir une logique métier indépendante et d'avoir la partie serveur de la logique de présentation en ASP, JSP ou autre. Ainsi, le vrai changement par rapport au web 2.0 est que la couche de présentation peut être entièrement en javascript. Personnellement, je préfère ça.


Eh bien, oui, je conviens que la logique métier ne devrait pas être dans un ASP. C'est le point de MVC.
Joe

Cette réponse remonte à près de deux ans, et maintenant des choses comme SproutCore font fureur. Sur le site Web de SproutCore, ils indiquent explicitement que l'objectif est de déplacer la logique métier vers le navigateur (voir: sproutcore.com/about ). Alors ... l'état du Web a-t-il changé maintenant? La logique métier sur le client (via JS dans le navigateur notamment) est-elle correcte ou peut-être même préférable?
JoeCool

@JoeCool SproutCore existait alors. Et les considérations de sécurité de la mise en logique métier sur le client n'ont pas changé. Mais toutes les applications n'ont pas beaucoup de problèmes de sécurité. En outre, "toute la rage" semble assez surestimé pour SproutCore. Mais la faisabilité de faire plus sur le client a continué d'augmenter - sauf que les appareils mobiles ont continué à gagner en importance et qu'ils restent difficiles en termes de performances pour de nombreuses applications.
psr

@psr Accordé - mais vous aviez juste l'air de complètement abandonner la logique métier dans le client, alors qu'en fait, au moins quelques technologies populaires se dirigent clairement dans cette direction.
JoeCool

6

Le JavaScript implémente souvent un service RESTful, ce qui signifie qu'il spécifie une requête de base de données.

C'est là que vous vous êtes trompé. REST n'est pas CRUD.

Les ressources exposées par REST ne sont pas vos enregistrements de base de données; ce sont des objets entièrement gérés qui se comportent selon votre logique métier. Lorsque le serveur reçoit un POST ou PUT, il ne doit pas simplement valider et stocker. Il doit effectuer tout ce qui est approprié pour l'application.

Exemple simple: une application de type Twitter reçoit des tweets sous forme de messages POST sur un conteneur donné. Le serveur analyse ensuite le contexte ("qui êtes-vous?", "De quel canal s'agit-il?") Et le contenu ("tous les hashtags?", Les index de texte, etc.) et stocke tout cela dans les files d'attente respectives. Ajoute probablement une référence directement à tous vos abonnés.

Cela représente beaucoup de travail au-delà de l'ajout de la ressource au conteneur, tout est défini par votre logique métier. Et il appartient au serveur.


2

Mes préoccupations avec cette approche peuvent être dues à une mauvaise compréhension de votre conception, alors n'hésitez pas à me tirer dessus.

pensez cependant à l'évolutivité, à la maintenabilité et à la sécurité du produit.

Si votre produit se développe massivement, la base de données devient le goulot d'étranglement, donc si les "performances" suggèrent d'intégrer la logique métier dans les procédures stockées, elles mettent une charge CPU supplémentaire sur votre serveur de base de données, faisant avancer le jour où le serveur atteint sa capacité maximale. Contrairement aux serveurs Web, les bases de données ACID ne sont pas facilement extensibles en utilisant du matériel parallèle. Si votre produit ne connaîtra jamais autant de succès, ce n'est pas un problème.

L'idée de maintenir la logique métier en javascript s'exécutant sur des navigateurs Web, où différents navigateurs requériront différents javascriopt, plusieurs versions de navigateurs, etc ... Pourquoi rendre ce problème plus compliqué qu'il ne l'est déjà?

Comme l'a dit Javiar, l'utilisation d'une approche REST comme API de base de données pour votre produit n'est vraiment pas judicieuse. Son avantage d'une interface REST est que d'autres personnes penseront alors à différentes manières d'utiliser et d'interroger votre interface REST. Cependant, il s'agit de ressources de logique métier post publique et non de ressources d'enregistrement de table de bas niveau. L'idée de rendre ces requêtes de données de bas niveau disponibles sur l'API HTTP ressemble à un cauchemar de sécurité.


+1, pour corrompre le problème de compatibilité du navigateur. En outre, l'écriture de code d'entreprise en JavaScript nécessite une compétence supplémentaire et ne vous permet pas d'utiliser des méthodes dans vos classes professionnelles.
NoChance

2

Bien qu'il existe de nombreuses écoles de pensée à ce sujet, et certainement aucune façon ne peut être qualifiée de "la bonne façon" universellement, tandis que toutes les autres sont "de la mauvaise façon" universellement, il existe un certain nombre de raisons pour isoler la logique métier côté serveur. et accédez à ces objets et services via un service RESTful.

La réponse courte est qu'il s'agit principalement de gestion des risques, de suivi et d'amélioration des performances.

En détail:

La raison primordiale numéro 1 est la sécurité. Il ne faut jamais faire confiance aux clients pour soumettre autre chose que des ordures au serveur, et en gardant les aspects de sécurité côté serveur, vous isolez le risque potentiel qu'un utilisateur voyou endommage votre système. Rappelez-vous, Javascript est complètement côté client et peut être modifié de manière triviale, vous ne pouvez donc PAS FAIRE CONFIANCE À LA SORTIE.

La raison numéro 2 est la séparation des préoccupations. Votre programmeur javascript n'est peut-être pas un expert en sécurité, et votre gourou de la sécurité n'est peut-être pas si bon en Javascript. En isolant la logique métier de la logique de présentation, vous évitez de traverser ces problèmes, car le javascript ne sera pas autorisé à accéder aux ressources au-delà de ses niveaux d'autorisation, et recevra des erreurs, dont la gestion est à la portée du programmeur de script. De même, le responsable de la sécurité ne déboguera pas Javascript pour voir comment la sécurité est maintenue.

La raison numéro 3 est la performance. La logique métier peut potentiellement exiger des ressources de serveur et de base de données. En gardant cette logique isolée de vos éléments d'interface utilisateur, vous pouvez ensuite mettre à l'échelle uniquement cette partie de votre application, ce qui facilite d'autant plus la résolution des goulots d'étranglement. De plus, il est beaucoup plus facile d'isoler le processus métier qui charge votre système ou votre base de données si les processus métier sont exécutés sur le serveur.

Un corollaire ici est que, souvent, plusieurs processus métier utilisent les mêmes données, et vous pouvez donc implémenter la mise en cache côté serveur pour réduire la charge globale du système qui pourrait ne pas être possible / sécurisé pour permettre aux clients d'accéder au code côté.

Enfin, je proposerais que pour maintenir les normes ACID, Business Logic ait vraiment besoin d'être sur le serveur. Je me souviens d'avoir conservé un produit de facturation qui fonctionnait dans le navigateur Web, avec seulement une connexion de base de données au serveur. Si la facturation quotidienne (qui pouvait prendre une heure ou plus par une bonne journée!) Était interrompue, par exemple, en fermant ou en plantant le navigateur, cela pourrait prendre plusieurs heures pour régler le gâchis qu'elle faisait de la base de données, qui a été laissé dans un état incohérent. N'oubliez pas que cela impliquait également les cartes de crédit, de sorte que les relevés de facturation devaient également être vérifiés par le processeur!

La logique métier côté serveur est généralement triviale pour assurer les mises à jour ACID, car il existe des cadres pour n'importe quelle langue pour gérer les transactions, au niveau de l'application ou de la base de données. Si vous le faites via plusieurs mises à jour à partir d'un client Web ... vous allez avoir un état incohérent à un moment donné, et cela va probablement affecter votre application.

Bien qu'il puisse être tentant de considérer les services RESTful comme un simple moyen d'accéder à la base de données, vous ne devriez pas tomber dans ce piège, car c'est une bonne recette pour un désastre. Le modèle d'objet que vous exposez via un service RESTful peut être lié à votre base de données, mais devrait vraiment encapsuler votre logique métier au lieu de simplement l'utiliser comme moteur CRUD.


+1 pour avoir récolté de nombreux bons points. Le système de facturation que vous avez utilisé comme exemple a la conception la plus étrange dont j'ai jamais entendu parler.
NoChance

Il portait aussi le nom le plus étrange dont j'aie jamais entendu parler, bien que j'en vois encore des références. Il s'appelait HURLnet ISP Admin et était tout à fait la créature à entretenir. Nous avions une licence de code source complète, et je l'ai largement utilisée une fois qu'ils ont cessé de la prendre en charge.
SplinterReality
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.