Декораторы по сравнению с классами в веб-разработке Python
Я заметил три основных пути веб-вручение запроса соглашения о платформах Python: декораторы, классы контроллера с методами для отдельных запросов и классы запроса с методами для ДОБИРАЮТСЯ/POST.
Мне любопытно на предмет достоинств этих трех подходов. Есть ли главные преимущества или недостатки к какому-либо из этих подходов? Для фиксации идей вот, три примера.
Бутылка использует декораторов:
@route('/')
def index():
return 'Hello World!'
Опоры используют классы контроллера:
class HelloController(BaseController):
def index(self):
return 'Hello World'
Торнадо использует классы обработчика запросов с методами для типов:
class MainHandler(tornado.web.RequestHandler):
def get(self):
self.write("Hello, world")
Какой стиль является лучшей практикой?
2 ответа
На самом деле для каждого из трех перечисленных вами методов есть своя причина, характерная для каждого проекта.
- Ботл старается сделать все как можно более простыми/прямыми, насколько это возможно для программиста. С декораторами для маршрутов вам не нужно беспокоиться о понимании разработчиком ООП.
- Цель разработки Pylons заключается в том, чтобы сделать код повторно используемым и легко интегрировать с HTTP в стиле WSGI маршрутизацией процессов. В связи с этим они выбрали очень ООП способ организации маршрутов. В качестве примера, вы можете скопировать и вставить HelloController в любое приложение Pylons, и оно просто волшебным образом работать. Даже если это приложение обслуживается через WSGI каким-то сложным образом.
- У Tornado есть еще одна причина для того. делать все так, как он делает: IOLoop Торнадо на основе epoll (в сочетании с tornado.web.Application) инстанцирует каждый RequestHandler по мере как только поступают запросы. Сохраняя каждый RequestHandler ограничивается определенным GET или POST, это позволяет IOLoop быстро инстанцировать класс, обработать запрос и, наконец, позволить он будет собран. Это сохраняет его быстрым и эффективным с небольшим объем памяти независимо от того, сколько сколько RequestHandlers у вашего приложения имеет. Это также является причиной того, что Tornado может обрабатывать намного больше одновременных запросов, чем другие веб-серверы на базе Python (каждый запрос получает свой собственный экземпляр).
Теперь, сказав все это, вы должны знать, что вы всегда можете переопределить поведение фреймворка по умолчанию. Например, я написал MethodDispatcher для Tornado, который заставляет его работать более похоже на Pylons (ну, я имел в виду CherryPy, когда писал его). Это немного замедляет работу Tornado (и немного увеличивает объем памяти) из-за наличия одного большого RequestHandler (по сравнению с множеством маленьких), но это может уменьшить количество кода в вашем приложении и сделать его немного легче для чтения (По моему предвзятому мнению, конечно =)).
Различные платформы пытаются достичь максимальной производительности с помощью наилучшего кода (для записи и чтения). Каждый из них использует разные стратегии, основанные на MVC или MVT.
То, на чем вы сосредоточены, вероятно, зависит от вашего личного вкуса. И мой ответ тоже. Я очень стараюсь избегать какой-либо священной войны, потому что могут быть веские технические аргументы, о которых я просто не знаю.
Но я лично предпочитаю хранить маршрутизацию отдельно от контроллера (представление django) и отдельно от него шаблоны. Это упрощает повторное использование контроллеров. Да, я пользователь Django.
Таким образом, я действительно не большой поклонник декораторов бутылки или упаковки вещей в большие, громоздкие классы. Раньше я был разработчиком ASP.NET, но Django освободил меня.