Eine kurze Analyse mehrerer häufig verwendeter Python-Web-Frameworks

Unter den verschiedenen Sprachplattformen hat Python wahrscheinlich die meisten Web-Frameworks hervorgebracht. Es ist eine Welt, in der unzählige Mikro-Frameworks und Frameworks blühen. Der Grund dafür könnte sein, dass es sehr einfach ist, ein Framework in Python zu erstellen , wodurch das Rad immer wieder erfunden wird. Also

Es gibt also immer wieder Themen in der Python-Community über die Vor- und Nachteile von Python-Frameworks. Lassen Sie mich Ihnen einige wichtige Python-Frameworks vorstellen:

Django

Django dürfte das bekannteste Py-Framework sein, Google App Engine und sogar Erlang hat Frameworks, die davon betroffen sind.

Django geht einen großen und umfassenden Weg. Es ist vor allem für sein vollständig automatisiertes Verwaltungs-Backend bekannt: Sie müssen nur das ORM verwenden und einfache Objektdefinitionen erstellen, und es kann automatisch generiert werden Datenbankstruktur und voll funktionsfähiges Verwaltungs-Backend.

Der von Django gebotene Komfort bedeutet auch, dass Djangos integriertes ORM eng mit anderen Modulen im Framework gekoppelt ist.

Die Anwendung muss das integrierte ORM von Django verwenden, sonst kann sie die verschiedenen Annehmlichkeiten, die das auf seinem ORM basierende Framework bietet, nicht nutzen ORM-Modul, aber das ist ziemlich. Wenn Sie das renovierte Haus abreißen und renovieren möchten, ist es besser, von Anfang an in das Rohbauhaus zu gehen und eine neue Dekoration vorzunehmen.

Djangos Verkaufsargument ist seine extrem hohe Entwicklungseffizienz, aber seine Leistungserweiterung ist begrenzt; Projekte, die Django verwenden, müssen neu aufgebaut werden, nachdem der Datenverkehr einen bestimmten Umfang erreicht hat, um die Leistungsanforderungen zu erfüllen.

Die Mängel von Django sind hauptsächlich darauf zurückzuführen, dass Django darauf besteht, alle seine eigenen Räder herzustellen. Das gesamte System ist relativ geschlossen:

· Das System ist eng gekoppelt. Wenn Sie der Meinung sind, dass eine bestimmte in Django integrierte Funktion nicht sehr gut ist, wird es schwierig sein, sie durch Ihre bevorzugte Bibliothek eines Drittanbieters zu ersetzen, z. B. das unten erwähnte ORM und die Vorlage. Es ist fast unmöglich, SQLAlchemy oder Mako in Django zu verwenden. Selbst wenn Sie einige Patches anwenden, werden Sie sich sehr, sehr unbehaglich fühlen.

· Das mit Django gelieferte ORM ist weitaus weniger leistungsfähig als SQLAlchemy. Mit Ausnahme von Django ist SQLAlchemy der De-facto-ORM-Standard in der Python-Welt, aber Django besteht immer noch darauf Satz. Die

-Entwickler haben auch versucht, SQLAlchemy zu unterstützen, haben aber schließlich aufgegeben. Es wird geschätzt, dass die Kosten zu hoch sind und die Integration mit anderen Django-Modulen schwierig ist.

· Die Template-Funktion ist relativ schwach und kann nicht in Python-Code eingefügt werden. Um komplexere Logik zu schreiben, müssen Sie Python zum Implementieren von Tag oder Filter verwenden. Das Design des Vorlagensystems von Django ist sehr interessant und dürfte auch der einflussreichste und umstrittenste Teil seines Frameworks sein.

Die Designphilosophie von Django-Vorlagen besteht darin, Code und Stile vollständig zu trennen. Asp.net befürwortet die Trennung von Code/Vorlagen, aber technisch gesehen können sie immer noch gemischt werden Möglichkeit der Kodierung und Verarbeitung von Daten in Vorlagen.

Zum Beispiel können Sie in der asp.net-Vorlage schreiben:

int i;

for( i= =0;i

....

}

%>

Django ist gründlich. Es unterstützt keinen Einbettungscode wie oben und kann nur die in seine Vorlage integrierten Funktionen verwenden. Tatsächlich erstellt es eine „neue Sprache“ für seine Vorlage, da diese „neue Sprache“ sehr einfach ist auch auf andere Plattformen übertragen werden.

In den meisten Fällen ist die Vorlagenfunktion von Django ausreichend, aber für besondere Situationen (manchmal ist „besonders“ nicht sehr speziell) müssen Sie immer noch Code in die Vorlage einbetten um die Vorlagenerweiterung gemäß den Regeln seines Vorlagensystems durchzuführen. Manchmal kann ein Problem, das durch das Schreiben von

direkt in die Vorlage mit einer Codezeile gelöst werden kann, nach der Implementierung mit der Vorlagenerweiterung zu mehr als einem Dutzend Codezeilen werden.

Ob das Programmieren in Templates toleriert wird, ist der umstrittenste Aspekt von Django-Templates.

Pylons & TurboGears & repoze.bfg

Neben Django ist Pylons der andere große, denn TurboGears2.x basiert auf Pylons. und repoze.bfg wurde auch in das große Projekt im TurboGears integriert und repoze.bfg wird später nicht separat besprochen.

Die Designkonzepte von Pylons und Django sind völlig unterschiedlich. Pylons selbst verfügt nur über etwa zweitausend Zeilen Python-Code, enthält aber auch einige Module von Drittanbietern, die fast von Pylons verwendet werden. Pylons bietet nur ein Regal und optionale Lösungen. Sie können Komponenten wie Vorlage, ORM, Formular, Authentifizierung usw. frei auswählen. Das System ist in hohem Maße anpassbar. Wir sagen oft, dass Python eine Leimsprache ist, daher können wir definitiv sagen, dass Pylons ein Leim-Framework ist, das mit der Leimsprache entwickelt wurde.

Die Entscheidung für Pylons bedeutet wahrscheinlich auch, dass Sie sich für die Freiheit entscheiden:

· Pylons ist ein Lernalbtraum und verlässt sich auf viele Bibliotheken von Drittanbietern. Sie werden nicht in Pylons hergestellt Wenn Sie Pylonen lernen, müssen Sie auch lernen, wie man diese Bibliotheken nutzt. Der Schlüssel liegt darin, dass Sie manchmal nicht wissen, was Sie lernen möchten. Die Lernkurve von Pylonen ist viel höher als die von Django und

Die frühere offizielle Dokumentation von Pylons war immer Gegenstand der Kritik. Glücklicherweise wurde das Buch „The Definitive Guide to Pylons“ später veröffentlicht, und diese Situation hat sich geändert. Aus diesem Grund galt Pylons einst als Python-Framework, das nur für Experten geeignet war.

· Das Debuggen ist ein Alptraum, da viele Module beteiligt sind und es schwierig ist, das Problem zu lokalisieren, sobald ein Fehler auftritt. Es kann an dem Programm liegen, das Sie geschrieben haben, oder es kann sein, dass Pylons falsch ist, oder dass SQLAlchemy falsch ist, oder vielleicht liegt ein Fehler im Formencode vor. Wie dem auch sei, es ist sehr chaotisch

. Dieses Problem lässt sich nur lösen, wenn man sich damit auskennt.

· Um Pylons zu installieren, müssen Sie fast 20 große und kleine Python-Module installieren, jedes mit seiner eigenen Versionsnummer. Grundsätzlich kann es bei jedem Modul zu Inkompatibilitätsproblemen kommen es ist sehr schwierig. Bisher steckt Reddits Pylons immer noch bei der antiken Version 0.9.6 von

fest, und SQLAlchemy ist immer noch bei Version 0.5.3, was damit zusammenhängen dürfte.

Die Integration von Pylons und repoze.bfg könnte das nächste Framework hervorbringen, das Djangos Status in Frage stellen kann.

Tornado & web.py

Tornado (http://www.tornadoweb.org) ist ein Open-Source-Framework von Facebook. Seine Philosophie ist fast das entgegengesetzte Extrem von Django. Tornado ist ein Webserver (hierauf wird in diesem Artikel nicht näher eingegangen) und außerdem ein Mikro-Framework ähnlich wie web.py.

Tornado geht in die Richtung von weniger, aber besser. Es bietet auch eine Vorlagenfunktion, obwohl dies nicht empfohlen wird, kann der Autor eine kleine Menge Codierung in der Vorlage zulassen (direkt einbetten). einzelne Zeile Py-Code).

Im Vergleich zu asp.net ist Tornado ein wenig ähnlich und implementiert nur AsyncHttpHandler; ansonsten müssen Sie alles selbst implementieren.

Nun, es verfügt tatsächlich über Vorlagen, internationale Unterstützung und sogar ein integriertes OAuth/OpenID-Modul, um die Anmeldung von Drittanbietern zu erleichtern. Es implementiert tatsächlich direkt den HTTP-Server.

Aber es gibt kein ORM (nur eine supereinfache Kapselung von MySQL), und es bietet nicht einmal Sitzungsunterstützung, geschweige denn ein automatisiertes Backend wie Django.

Angenommen, es handelt sich um eine große Website. Aufgrund der hohen Leistungsanforderungen muss häufig jeder Teil des Frameworks angepasst werden, und es gibt nur sehr wenige Module, die für eine wiederverwendet werden können Mit Django entwickelte Website. Nach einigen kontinuierlichen Anpassungen ist das, was vom Django-Framework übrig bleibt, höchstwahrscheinlich das, was Tornado von Anfang an bieten kann.

Verschiedene Wege führen zum gleichen Ziel.

HTTP-Server

Tornado bettet den HTTP-Server direkt ein, um den asynchronen Aufruf von Comet/Backend an die HTTP-Schnittstelle effizient zu implementieren.

Auf das Frontend kann über den Browser zugegriffen werden, ohne dass Apache/lighttpd/nginx usw. hinzugefügt werden muss. Das HTTP 1.1-Protokoll wird jedoch nicht vollständig implementiert. Daher empfiehlt das offizielle Dokument Benutzern dies Verwenden Sie es in einer Produktionsumgebung. Das Front-End verwendet Nginx und das Back-End einen Reverse-Proxy für mehrere Tornado-Instanzen.

Tornado selbst ist ein asynchrones Single-Thread-Netzwerkprogramm. Wenn es standardmäßig gestartet wird, werden mehrere Instanzen entsprechend der Anzahl der CPUs ausgeführt CPU.

Single-Threaded Asynchronous

Websites verfügen grundsätzlich über Datenbankoperationen, und Tornado ist Single-Threaded, was bedeutet, dass der gesamte Server antwortet, wenn die Datenbankabfrage zu langsam zurückkommt wird verstopft sein.

Datenbankabfragen sind im Wesentlichen Remote-Netzwerkaufrufe; idealerweise würden diese Vorgänge als asynchrone Vorgänge gekapselt, Tornado bietet hierfür jedoch keine Unterstützung.

Damit ein System hohen Datenverkehr bewältigen kann, muss das Problem der Datenbankabfragegeschwindigkeit gelöst werden!

Wenn in der Datenbank ein Problem mit der Abfrageleistung auftritt, stellt die Datenbank unabhängig davon, wie das gesamte System optimiert ist, einen Engpass dar und verlangsamt das gesamte System!

Asynchron verbessert nicht unbedingt die Leistung des Systems; es vermeidet lediglich unnötiges Warten auf Netzwerkantworten und den CPU-Verbrauch beim Wechseln von Threads.

Wenn die Antwort auf die Datenbankabfrage zu langsam ist, muss das Leistungsproblem der Datenbank gelöst werden und nicht die Front-End-Webanwendung, die die Datenbank aufruft.

Für eine Echtzeit-Rückgabedatenabfrage muss im Idealfall sichergestellt werden, dass sich alle Daten im Speicher befinden und die Datenbank-Festplatten-E/A 0 sein sollte; eine solche Abfrage kann schnell genug sein; und wenn die Datenbankabfrage schnell genug ist, müssen Front-End-Webanwendungen keine Datenabfragen als asynchrone Kapselung

durchführen.

Selbst wenn Sie Coroutinen verwenden, erhöhen asynchrone Programme immer die Komplexität synchroner Programme. Es muss geprüft werden, ob es sich lohnt, mit der zusätzlichen Komplexität umzugehen.

Wenn es Abfragen im Backend gibt, die zu langsam sind, um umgangen zu werden, empfiehlt Tornaod, diese Abfragen unabhängig im Backend in eine HTTP-Schnittstelle zu kapseln und dann die integrierte asynchrone Schnittstelle von Tornado zu verwenden HTTP Der Client führt den Anruf durch.