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

Я заметил три основных способа: веб-фреймы 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")

Какой стиль лучше всего подходит?

Ответы

Ответ 1

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

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

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

Ответ 2

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

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

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

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