Dekorateure gegen Klassen in der Python -Webentwicklung

Question

Ich habe drei Hauptmethoden festgestellt, wie Python Web Frameworks -Anfragen beantragt wird: Dekorateure, Controller -Klassen mit Methoden für einzelne Anfragen und Anforderungsklassen mit Methoden zum Get/Post.

Ich bin gespannt auf die Tugenden dieser drei Ansätze. Gibt es wichtige Vor- oder Nachteile für einen dieser Ansätze? Um Ideen zu beheben, finden Sie hier drei Beispiele.

Flasche Verwendet Dekorateure:

@route('/')
def index():
    return 'Hello World!'

Pylonen Verwendet Controller -Klassen:

class HelloController(BaseController):
    def index(self):
        return 'Hello World'

Tornado Verwendet Anforderungshandlerklassen mit Methoden für Typen:

 class MainHandler(tornado.web.RequestHandler):
    def get(self):
        self.write("Hello, world")

Welcher Stil ist die beste Praxis?

Answer 1

Es gibt tatsächlich einen Grund für jede der drei aufgelisteten Methoden, die für jedes Projekt spezifisch sind.

• Die Flasche versucht, die Dinge für den Programmierer so einfach/unkompliziert wie möglich zu halten. Mit Dekoratoren für Routen müssen Sie sich keine Sorgen um den Entwicklerverständnis OOP machen.
• Pylons-Entwicklungsziel ist es, Code wiederverwendbar zu machen und leicht in das HTTP-Prozessrouting im WSGI-Stil integriert zu werden. Als solche haben sie eine sehr oop -Art der Organisation von Routen gewählt. Zum Beispiel können Sie Hellocontroller in jede Pylons -App kopieren und einfügen, und es sollte einfach auf magische Weise funktionieren. Auch wenn diese App über WSGI auf komplizierte Weise serviert wird.
• Tornado hat einen weiteren Grund dafür, Dinge so zu tun, wie es tut: Tornados Epoll-basierte IOLOOP (in Verbindung mit Tornado.Web.Application) instanziiert jeden RequestHandler, wenn Anfragen eintreten. Indem jeder RequestHandler auf einen bestimmten Get oder Post beschränkt ist Um die Klasse schnell zu instanziieren, verarbeiten Sie die Anfrage und lassen Sie sie schließlich Müll gesammelt. Dies hält es schnell und effizient mit einem kleinen Speicherausdruck, unabhängig davon, wie viele RequestHandler Ihre Anwendung hat. Dies ist auch der Grund, warum Tornado so viele weitere gleichzeitige Anfragen bearbeiten kann als andere pythonbasierte Webserver (jede Anfrage erhält eine eigene Instanz).

Nachdem Sie alles gesagt haben, was Sie wissen sollten, dass Sie das Standard -Framework -Verhalten immer überschreiben können. Zum Beispiel habe ich a geschrieben MethodDispatcher Für Tornado, das es eher wie Pylone funktioniert (nun, ich hatte Cherrypy im Sinn, als ich es schrieb). Es verlangsamt den Tornado um eine winzige Menge (und erhöht den Speicher Fußabdruck gering (Meiner voreingenommenen Meinung, natürlich =).

Answer 2

Die verschiedenen Frameworks versuchen, die beste Leistung durch den besten Code (zum Schreiben und Lesen) zu erzielen. Sie nehmen jeweils unterschiedliche Strategien an, die auf oder um MVC oder MVT basieren.

Worauf Sie sich konzentrieren, wird wahrscheinlich auf den persönlichen Geschmack kommen. Und meine Antwort auch. Ich bemühe mich sehr, irgendeine Art von heiligem Krieg zu vermeiden, da es möglicherweise gültige technische Argumente geben, von denen ich einfach nicht weiß.

Aber ich persönlich Zulassen Sie es vor, das Routing vom Controller (Django -Ansicht) getrennt zu halten und von diesem zu trennen. Es macht die Wiederverwendung von Controllern sehr einfach. Ja, ich bin ein Django -Benutzer.

Als solches bin ich wirklich kein großer Fan von Flaschendekoratoren oder wickle Dinge in großen Hulking -Klassen ein. Ich habe es gewöhnt, als ich ein ASP.NET -Entwickler war, aber Django hat mich frei gemacht.