Декораторы против классов в веб-разработке на Python - PullRequest
Новая
       32

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

10 голосов
/ 06 июня 2010

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

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

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

@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")

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

Ответы [ 2 ]

10 голосов
/ 06 июня 2010

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

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

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

1 голос
/ 06 июня 2010

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

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

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

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

...