Erhalten Sie ein umfassendes Verständnis 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

In der Python-Community gibt es immer Themen darüber, welches Python-Framework besser oder schlechter ist. Lassen Sie mich Ihnen einige wichtige Python-Frameworks vorstellen:

Django

Django sollte das bekannteste Py-Framework von Google App Engine sein und sogar Erlang verfügt über Frameworks, die es unterstützen. Beeinflussen.

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 ORM verwenden und einfache Objektdefinitionen erstellen, und es kann automatisch Datenbankstrukturen und vollständige Funktionen generieren Hintergrund.

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 ORM-basierten Annehmlichkeiten des Frameworks nicht nutzen. Theoretisch können Sie das ORM-Modul austauschen, aber das ist gleichwertig zur Renovierung des fertigen Hauses Wenn das Haus abgerissen und renoviert werden soll, ist es besser, ins Rohbauhaus zu gehen, um von Anfang an eine brandneue Dekoration vorzunehmen.

Das Verkaufsargument von Django ist seine extrem hohe Entwicklungseffizienz, aber seine Leistungserweiterung ist begrenzt; Projekte, die Django verwenden, müssen rekonstruiert 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. Die am meisten kritisierten Aspekte von Django sind:

· Das System ist eng gekoppelt. Wenn Sie denken, dass Django über eine integrierte Funktion verfügt, ist eine bestimmte Funktion nicht sehr gut und es ist schwierig, sie durch Ihre bevorzugte Bibliothek von Drittanbietern zu ersetzen, z. B. ORM und Template, die unten erwähnt werden. Es ist fast unmöglich, SQLAlchemy oder Mako in Django zu verwenden, und selbst mit einigen Patches werden Sie sich dadurch 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 von Django 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 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 Verarbeitung von Daten.

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

<%

int i;

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

....

}

%>

Django unterstützt keinen Einbettungscode ähnlich dem oben genannten unter Alles in allem können Sie nur die integrierten Funktionen seiner Vorlagen verwenden. Tatsächlich wird eine „neue Sprache“ für seine Vorlagen erstellt. Da diese „neue Sprache“ sehr einfach ist, können ihre Vorlagen auch auf verschiedene Plattformen portiert 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 und dann die Regeln des Vorlagensystems befolgen zur Vorlagenerweiterung. 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 Vorlagen toleriert wird, ist der umstrittenste Aspekt von Django-Vorlagen.

Pylons & TurboGears & repoze.bfg

Neben Django ist Pylons das andere große, denn TurboGears2.x basiert auf Pylons, und repoze.bfg auch Es wurde in das große Projekt Pylons integriert, und TurboGears und repoze.bfg werden 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 Optionen, Sie können es nach Ihren eigenen Vorlieben anpassen

Durch die freie Auswahl von Komponenten wie Vorlage, ORM, Formular, Authentifizierung usw. ist das System 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 man manchmal nicht weiß, was man lernen möchte. Die Lernkurve von Pylons ist viel höher als die von Django, und die offizielle Dokumentation von Pylons wurde zum Glück später veröffentlicht. Diese Situation wurde gelöst. Aus diesem Grund galt Pylons einst als Python-Framework, das nur für Experten geeignet war.

· Debugging-Albtraum, da viele Module beteiligt sind, ist es schwierig, 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, jedenfalls ist es 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 einer eigenen Versionsnummer. Bei jedem Modul besteht die Möglichkeit einer Inkompatibilität . Upgrade Im Grunde ist es sehr schwierig. Bisher hängen die Pylons von reddit immer noch an der

antiken Version 0.9.6 fest, und SQLAlchemy befindet sich immer noch an der 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 Gegenteil 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 mehr Präzision. Es bietet auch eine Vorlagenfunktion, obwohl dies nicht empfohlen wird. Der Autor kann jedoch eine kleine Menge Codierung in der Vorlage zulassen (direktes Einbetten einer einzelnen Zeile Py-Code). ).

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

Tja, tatsächlich verfügt es über Vorlagen, Unterstützung für die Internationalisierung 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 gibt nicht einmal Sitzungsunterstützung, geschweige denn ein automatisiertes Backend wie Django.

Angenommen, es handelt sich um eine große Website, bei der häufig jeder Teil des Frameworks angepasst werden muss und es nur sehr wenige Module gibt, die für eine mit Django entwickelte Website wiederverwendet werden können Ein Teil wurde kontinuierlich angepasst, der Rest des Django-Frameworks ist 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 Comet/Backend-Aufruf der HTTP-Schnittstelle effizient zu implementieren. Der Browser kann auf das Front-End zugreifen, ohne Apache/lighttpd/nginx usw. hinzuzufügen. Es implementiert jedoch das HTTP 1.1-Protokoll nicht vollständig. Daher empfiehlt das offizielle Dokument Benutzern, Nginx auf der Vorderseite zu verwenden -End und Back-End in einer Produktionsumgebung 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.

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; im Idealfall 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 es das Problem der Datenbankabfragegeschwindigkeit lösen!

Wenn es ein Problem mit der Abfrageleistung in der Datenbank gibt, stellt die Datenbank, egal wie optimiert das gesamte System ist, einen Engpass dar und verlangsamt das gesamte System!

Asynchron verbessert nicht grundsätzlich die Systemleistung; 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, nicht das der Front-End-Webanwendung, die die Datenbank aufruft.

Für die Abfrage zurückgegebener Daten in Echtzeit muss sichergestellt werden, dass sich alle Daten im Speicher befinden und die Datenbank-Festplatten-IO nur dann schnell genug sein kann, wenn die Datenbankabfrage schnell genug ist , dann ist die Front-End-Webanwendung nicht in der Lage, die Datenabfrage als asynchron zu kapseln

.

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 Abfragen im Backend zu langsam sind und nicht umgangen werden können, empfiehlt Tornaod, diese Abfragen unabhängig im Backend in HTTP-Schnittstellen zu kapseln und dann den integrierten asynchronen HTTP-Client von Tornado für Aufrufe zu verwenden .

Das obige ist der detaillierte Inhalt vonErhalten Sie ein umfassendes Verständnis mehrerer häufig verwendeter Python-Web-Frameworks. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!