Obtenez une compréhension approfondie de plusieurs frameworks Web Python couramment utilisés

Parmi les différentes plates-formes linguistiques, Python a probablement le plus de frameworks Web émergents. C'est un monde où une centaine de fleurs s'épanouissent, avec d'innombrables micro-frameworks et frameworks. La raison peut être qu'il est très simple de construire un framework en Python. , ce qui fait que la roue continue d'être inventée. Donc

Il y a toujours des sujets dans la communauté Python sur lesquels le framework Python est meilleur ou pire. Permettez-moi de vous présenter plusieurs frameworks python majeurs :

Django

Django devrait être le framework py le plus célèbre de Google App Engine et même Erlang a des frameworks qui le prennent en charge. Influence.

Django prend une direction vaste et globale. Il est surtout connu pour son backend de gestion entièrement automatisé : il vous suffit d'utiliser ORM et de définir des objets simples, et il peut générer automatiquement des structures de base de données et une gestion complète. arrière-plan.

La commodité fournie par Django signifie également que l'ORM intégré de Django est fortement couplé aux autres modules du framework.

L'application doit utiliser l'ORM intégré de Django, sinon elle ne pourra pas profiter des différentes commodités basées sur l'ORM fournies dans le framework en théorie, vous pouvez désactiver son module ORM, mais c'est équivalent ; à rénover l'achevé Si la maison doit être démolie et rénovée, il vaut mieux aller à la maison brute pour faire une

toute nouvelle décoration dès le début.

L'argument de vente de Django est son efficacité de développement ultra-élevée, mais son expansion des performances est limitée ; les projets utilisant Django doivent être restructurés une fois que le trafic atteint une certaine échelle pour répondre aux exigences de performances.

Les défauts de Django proviennent principalement de l'insistance de Django à fabriquer toutes ses propres roues. L'ensemble du système est relativement fermé. Les aspects les plus critiqués de Django sont :

· Le système est étroitement couplé. Si vous pensez que Django a intégré Une certaine fonction de celui-ci n'est pas très bonne et il est difficile de la remplacer par votre bibliothèque tierce préférée, telle que l'ORM et le modèle qui seront mentionnés ci-dessous. Il est presque impossible d'utiliser SQLAlchemy ou Mako dans Django, et même avec quelques correctifs, cela vous mettra très, très mal à l'aise.

· L'ORM fourni avec Django est beaucoup moins puissant que SQLAlchemy À l'exception de Django, SQLAlchemy est le standard ORM de facto dans le monde Python. D'autres frameworks prennent en charge SQLAlchemy, mais Django insiste toujours sur ce point. ensemble. Les développeurs

de Django ont également discuté et essayé de prendre en charge SQLAlchemy, mais ont finalement abandonné. On estime que le coût est trop élevé et qu'il est difficile à intégrer avec d'autres modules Django.

· La fonction Template est relativement faible et ne peut pas être insérée dans le code Python. Pour écrire une logique plus complexe, vous devez utiliser Python pour implémenter Tag ou Filter. La conception du système de modèles de Django est très intéressante et devrait constituer la partie la plus influente et la plus controversée de son framework.

La philosophie de conception des modèles Django est de séparer complètement le code et les styles ; asp.net préconise la séparation du code/des modèles, mais techniquement, ils peuvent toujours être mélangés et Django élimine fondamentalement le codage dans les modèles, la possibilité de le faire. traitement des données.

Par exemple, dans le modèle asp.net, vous pouvez écrire :

<%

int i;

for(i==0; i< 10;i++){

....

}

%>

Django ne prend pas en charge l'intégration de code similaire à celui ci-dessus tout, vous ne pouvez utiliser que les fonctions intégrées de ses modèles ; en fait, il construit un « nouveau langage » pour ses modèles ; car ce « nouveau langage » est très simple, ses modèles peuvent également être portés sur différentes plateformes.

Dans la plupart des cas, la fonction de modèle de Django est suffisante, mais pour des situations spéciales (parfois « spécial » n'est pas très spécial), vous devez toujours intégrer du code dans le modèle, puis vous devez suivre son système de modèles. les règles sont utilisées pour l’expansion du modèle. Parfois, un problème qui peut être résolu en écrivant

directement dans le modèle avec une seule ligne de code deviendra plus d'une douzaine de lignes de code après avoir été implémenté avec l'extension de modèle.

La question de savoir si la programmation dans des modèles est tolérée est l'aspect le plus controversé des modèles Django.

En plus de Django, l'autre grand est Pylons, car TurboGears2.x est basé sur Pylons, et repoze.bfg est également Il a été incorporé dans le grand projet Pylons, et TurboGears et repoze.bfg ne seront pas discutés séparément plus tard.

Les concepts de conception de Pylons et de Django sont complètement différents. Pylons lui-même ne contient qu'environ deux mille lignes de code Python, mais il est également livré avec des modules tiers qui sont presque utilisés par Pylons. Pylons ne propose qu'une seule étagère et des options, vous pouvez la personnaliser selon vos propres préférences

Avec une sélection gratuite de composants tels que modèle, ORM, formulaire, authentification, etc., le système est hautement personnalisable. Nous disons souvent que Python est un langage de colle, nous pouvons donc certainement dire que Pylons est un framework de colle conçu avec un langage de colle.

Choisir Pylons, c'est probablement choisir sa liberté Choisir la liberté, c'est aussi choisir le cauchemar :

· Cauchemar d'apprentissage, Pylons s'appuie sur de nombreuses bibliothèques tierces, elles ne sont pas Made in Pylons, quand à elles. vous apprenez Pylons, vous devez également apprendre à utiliser ces bibliothèques. La clé est parfois que vous ne savez pas ce que vous voulez apprendre. La courbe d'apprentissage de Pylons est bien plus élevée que celle de Django, et la documentation officielle de Pylons a été la cible de critiques. Heureusement, le livre The Definitive Guide to Pylons a été publié plus tard. Cette situation a été résolue. Quelque chose a changé. Pour cette raison, Pylons était autrefois connu comme un framework Python réservé aux experts.

· Cauchemar de débogage, car de nombreux modules sont impliqués, il est difficile de localiser le problème une fois qu'une erreur se produit. Cela peut être la faute du programme que vous avez écrit, ou il se peut que Pylons soit faux, ou que SQLAlchemy soit faux, ou peut-être qu'il y a un bug dans le formencode. Quoi qu'il en soit, c'est très compliqué

. Ce problème ne peut être résolu que si vous le connaissez.

· Cauchemar de mise à niveau. Pour installer Pylons, vous devez installer près de 20 modules Python, grands et petits, chacun avec son propre numéro de version. Pour mettre à niveau la version de Pylons, il existe une possibilité d'incompatibilité dans n'importe quel module. . Mettre à niveau En gros, c'est très difficile. Jusqu'à présent, les Pylônes de Reddit sont toujours bloqués à la

version antique 0.9.6, et SQLAlchemy est toujours à la version 0.5.3, ce qui devrait être lié à cela.

L'intégration de Pylons et repoze.bfg pourrait donner naissance au prochain framework qui pourra remettre en question le statut de Django.

Tornado ( http://www.tornadoweb.org ) est un framework open source de Facebook. Sa philosophie est presque à l'opposé de celle de Facebook. Django. Tornado est un serveur Web (cet article ne détaillera pas ce point), et c'est aussi un micro-framework similaire à web.py.

Tornado prend la direction de moins mais mieux. Il fournit également une fonction de modèle bien que cela ne soit pas encouragé, l'auteur peut autoriser une petite quantité de codage dans le modèle (intégrant directement une seule ligne de code py) ; .

Par rapport à asp.net, Tornado est un peu similaire et n'implémente qu'AsyncHttpHandler, à part cela, vous devez tout implémenter vous-même.

Eh bien, en fait, il dispose de modèles, d'un support d'internationalisation et même d'un module OAuth/OpenID intégré pour faciliter la connexion de tiers. Il implémente en fait directement le serveur HTTP.

Mais il n'a pas d'ORM (seulement une encapsulation super simple de MySQL), et il n'a même pas de support de session, encore moins de backend automatisé comme Django.

Supposons qu'il s'agisse d'un grand site Web. Sous l'exigence de hautes performances, chaque partie du framework doit souvent être personnalisée, et il existe très peu de modules qui peuvent être réutilisés pour un site Web développé avec Django. Une partie a été continuellement personnalisée. Le reste du framework Django est très probablement ce que tornado peut fournir depuis le début.

Différents chemins mènent à la même destination.

Tornado embarque directement le serveur HTTP afin d'implémenter efficacement les appels asynchrones Comet/backend de l'interface HTTP. Le front-end est accessible par le navigateur sans ajouter apache/lighttpd/nginx, etc. ; mais il n'implémente pas entièrement le protocole HTTP 1.1, le document officiel recommande donc aux utilisateurs d'utiliser nginx au front-end. -end et back-end dans l'environnement de production Proxy inverse vers plusieurs instances Tornado.

Tornado lui-même est un programme réseau asynchrone monothread Lorsqu'il est démarré par défaut, il exécutera plusieurs instances en fonction du nombre de processeurs en tirant pleinement parti du processeur multicœur.

Les sites Web ont essentiellement des opérations de base de données, et Tornado est monothread, ce qui signifie que si la requête de base de données revient trop lentement, la réponse entière du serveur sera bouché. Les requêtes de base de données sont essentiellement des appels réseau distants ; idéalement, ces opérations seraient encapsulées comme asynchrones, mais Tornado ne fournit aucune prise en charge pour cela ;

Pour qu'un système puisse répondre à un trafic élevé, il doit résoudre le problème de la vitesse des requêtes dans la base de données !

S'il y a un problème de performances des requêtes dans la base de données, quelle que soit la façon dont l'ensemble du système est optimisé, la base de données constituera un goulot d'étranglement et ralentira l'ensemble du système !

L'asynchrone n'améliore pas en soi les performances du système ; il évite simplement l'attente inutile des réponses du réseau et la consommation du processeur des threads de commutation.

Si la réponse à la requête de la base de données est trop lente, ce qui doit être résolu est le problème de performances de la base de données ; et non l'application Web frontale qui appelle la base de données.

Pour une requête de données renvoyées en temps réel, idéalement, il est nécessaire de s'assurer que toutes les données sont en mémoire et que l'entrée/sortie du disque dur de la base de données doit être 0 ; seule une telle requête peut être suffisamment rapide et si la requête de la base de données est suffisamment rapide ; , alors l'application Web frontale ne pourra pas. Il est nécessaire d'encapsuler la requête de données de manière asynchrone

.

Même si vous utilisez des coroutines, les programmes asynchrones augmenteront toujours la complexité des programmes synchrones ; ce qu'il faut mesurer, c'est si la gestion de la complexité supplémentaire en vaut la peine.

S'il y a des requêtes sur le backend qui sont trop lentes et ne peuvent pas être contournées, la suggestion de Tornaod est d'encapsuler ces requêtes indépendamment dans le backend dans des interfaces HTTP, puis d'utiliser le client HTTP asynchrone intégré de Tornado pour les appeler. .

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!