Декораторы против классов в веб-разработке python

Question

Я заметил три основных способа: веб-фреймы Python обрабатывают запрос: декораторы, классы контроллеров с методами для отдельных запросов и классы запросов с методами для GET/POST.

Мне любопытно о достоинствах этих трех подходов. Существуют ли существенные преимущества или недостатки любого из этих подходов? Чтобы исправить идеи, вот три примера.

Bottle использует декоратор:

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

Pylons использует классы контроллеров:

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

Tornado использует запрос классы обработчиков с методами для типов:

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

Какого стилем является лучшей практикой ?

Answer 1

На самом деле есть причина для каждого из трех перечисленных вами методов, специфичных для каждого проекта.

• бутылки пытается сохранить вещи, как простой/простой как можно для программиста. С декораторами для маршрутов вам не нужно беспокоиться о понимании разработчика ООП.
• Цель разработки Pylons состоит в том, чтобы сделать код повторно пригодным для использования и быть легко интегрирован с HTTP-интерфейсом WSGI HTTP маршрутизация процесса. Таким образом, у них выбрал очень способ ООП для организации маршрутов. Например, вы могли бы копия & вставить HelloController в любое приложение Pylons, и оно должно только волшебным образом работать. Даже если указанное приложение подается через WSGI в некотором сложном способе.
• Торнадо есть еще одна причина для делать вещи так, как это делает: Epoll основе IOLoop Tornado (в сочетании с tornado.web.Application) инициализирует каждый RequestHandler, как запросы поступают в.Сохраняя каждый RequestHandler, ограниченным определенным GET или POST, это позволяет IOLoop быстро создать экземпляр класса, обработать запрос и, наконец, дать , он получает собранный мусор. Это держит быстро и эффективно с небольшим размером памяти независимо от того, как у многих RequestHandlers ваше приложение имеет. Это также является причиной того, что Tornado может обрабатывать гораздо больше одновременных запросов, чем другие веб-серверы на базе Python (каждый запрос получает свой собственный экземпляр).

Теперь, сказав все, что вы должны знать, что вы всегда можете переопределить поведение каркаса по умолчанию. Например, я написал MethodDispatcher для Tornado, что делает его более похожим на Pylons (ну, я имел в виду CherryPy, когда писал). Это замедляет Tornado незначительное количество (и немного увеличивает объем памяти) из-за наличия одного большого RequestHandler (в отличие от множества небольших), но это может уменьшить количество кода в вашем приложении и сделать его немного легче читать (По моему смещенному мнению, конечно =).

Answer 2

Различные каркасы стараются достичь наилучшего результата благодаря лучшему коду (для записи и чтения). Каждый из них использует различные стратегии, основанные на MVC или MVT или вокруг них.

То, что вы фокусируетесь, вероятно, сходит на личный вкус. И мой ответ. Я очень стараюсь избежать какой-либо священной войны, потому что могут быть веские технические аргументы, о которых я просто не знаю.

Лично я лично предпочитают оставлять маршрутизацию отдельно от контроллера (вид django) и шаблонов отдельно от этого. Это делает повторное использование контроллеров очень простым. Да, я пользователь Django.

Как таковой, я действительно не большой поклонник декораторов Бутылки или обертывание вещей в больших больших классах. Раньше я был разработчиком ASP.NET, но Django освободил меня.