Dekoratory a klasy w rozwoju sieci Pythona

Question

Zauważyłem trzy główne sposoby rozdawania żądań w sieci Pythona: dekoratory, klasy kontrolerów z metodami dla indywidualnych żądań i klasy żądań z metodami GET/POST.

Ciekawi mnie zaleta tych trzech podejść. Czy są jakieś główne zalety lub wady któregokolwiek z tych podejść? Aby naprawić pomysły, oto trzy przykłady.

Bottle wykorzystuje dekoratorów:

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

Pylons używa klas kontrolera:

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

Tornado używa żądania klas procedur obsługi z metod dla typów:

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

Który styl jest najlepsza praktyka ?

Answer 1

Istnieje właściwie uzasadnienie dla każdej z trzech wymienionych metod, właściwych dla każdego projektu.

• Butelka stara się utrzymać wszystko jak prosty/prosty, jak to możliwe dla programisty. Z dekoratorami dla tras nie musisz się martwić o zrozumieniu deweloperów OOP.
• Celem rozwoju pylonów jest sprawienie, by był ponownie użyteczny i był łatwy w użyciu zintegrowany z routingiem procesorowym w stylu WSGI w standardzie HTTP . Jako takie, mają one wybrany bardzo sposób OOP organizacji tras . Na przykład, możesz skopiować & wkleić HelloController do dowolnej aplikacji Pylons i powinien po prostu magicznie pracować. Nawet jeśli wspomniana aplikacja jest serwowana za pośrednictwem WSGI w jakimś skomplikowanej modzie.
• Tornado ma kolejny powód do robienia rzeczy po drodze robi: epoll oparte IOLoop Tornado (w połączeniu z tornado.web.Application) instancję każdej RequestHandler jak wnioski przyjść.Utrzymanie każdego żądania ograniczonego do określonego RequestHandler do określonego GET lub POST pozwala IOLoop na szybko utworzyć instancję klasy, przetworzyć żądanie, a na końcu pozwolić uzyskać zbieranie śmieci. Zapewnia to szybką i wydajną pracę z niewielkim rozmiarem pamięci , niezależnie od tego, jak wiele aplikacji RequestHandlers ma w swojej aplikacji . Jest to również powód, dla którego Tornado może obsługiwać wiele więcej równoczesnych żądań niż inne serwery WWW oparte na Pythonie (każde żądanie otrzymuje własną instancję).

Teraz, po powiedzieliśmy wszystko, co powinieneś wiedzieć, że zawsze możesz zastąpić domyślne zachowanie struktury. Na przykład napisałem dla Tornado MethodDispatcher, który sprawia, że ​​działa bardziej jak Pylony (cóż, miałem na myśli CherryPy, kiedy to napisałem). Spowalnia Tornado w niewielkiej ilości (i nieznacznie zwiększa ślad pamięci) dzięki posiadaniu jednego dużego requestHandlera (w przeciwieństwie do wielu małych), ale może zmniejszyć ilość kodu w aplikacji i sprawić, że będzie on trochę łatwiejszy do odczytania (W mojej stronniczej opinii, oczywiście =).

Answer 2

Różne schematy próbują osiągnąć najlepszą wydajność za pomocą najlepszego kodu (do pisania i czytania). Każda z nich przyjmuje różne strategie oparte na MVC lub MVT.

To, na czym się koncentrujesz, prawdopodobnie sprowadza się do osobistego gustu. I tak będzie moja odpowiedź. Bardzo się staram, aby uniknąć jakiejkolwiek świętej wojny, ponieważ mogą istnieć ważne techniczne argumenty, o których po prostu nie wiem.

Ale osobiście osobiście wolę trzymać routing oddzielnie od kontrolera (widok Django) i szablon oddzielnie. Dzięki temu ponowne używanie kontrolerów jest naprawdę proste. Tak, jestem użytkownikiem Django.

Jako taki, naprawdę nie jestem wielkim fanem dekoratorów butelek lub owijania rzeczy w wielkich, wielkich klasach. Kiedyś byłem programistą ASP.NET, ale Django mnie uwolnił.