Использование классов для представлений Django, это Pythonic?

Question

В настоящее время я изучаю Python и имею опыт работы с C #. Я продолжаю слышать о том, как делать что-то на Pythonic, чтобы воспользоваться динамической природой языка, и некоторые из них я получаю, а некоторые нет.

Я создаю сайт с Django, и мой подход к просмотру заключается в использовании классов. В настоящее время я думаю о том, чтобы иметь базовый класс, в котором есть кое-что о шаблоне и используемой модели. Это будет страница по умолчанию в стиле фанк 404 с поиском по сайту и прочим материалом, а затем все остальные страницы будут основаны на этом. Таким образом, каждая область сайта будет иметь свои собственные новости EG, и все функции, связанные с моделью, и фильтрация будут в этом классе с дополнительным классом для запросов HTML или AJAX. Таким образом, у вас будет что-то вроде этого:

\ сайт \ Common \ ViewBase

- \ Новости \ NewsBase (ViewBase)

- \ Новости \ HtmlView (NewsBase)

- \ Новости \ AJAXView (NewsBase)

URL-адреса будут отображаться так же, как http://tld/news/latest отображается на site.news.htmlview, а http://tld/news//to/ также будет отображаться на site.news.htmlview, но класс будет выяснять, что делать с дополнительными Титулы.

Это почти то же самое, что я делал бы в C #, но в учебнике по Django показано только использование методов для представлений, что заставляет меня задаться вопросом, не является ли это не очень питоническим решением?

Мысли

Редактировать: После того, как С.Лотт прокомментировал безопасность потоков, лучше ли оставить функции такими, какие они есть, и заставить их создать экземпляр класса и вызвать для него метод?

Я ищу место для размещения общего кода для каждого раздела сайта для фильтрации модели, аутентификации для сайта и т. Д.

Answer 1

Конечно, нет ничего плохого в том, чтобы использовать класс для представления, если вы направите URL-адрес к реальному экземпляру класса, а не просто к классу напрямую.

Answer 2

Администратор Django делает именно это - посмотрите на исходный код в django / contrib / admin.

Преимущество классов в том, что их гораздо проще настраивать, например, вы можете добавить хуки для проверки прав доступа.

Существует предложение перенести все существующие общие представления в классы, он должен был попасть в 1.2, но не уложился в срок.

Как указывает приведенный выше плакат, будьте очень осторожны с обработкой переменных экземпляра - если вы посмотрите на классы администратора, вы увидите, что запрос передается различным методам вместо того, чтобы полагаться на "self".

Answer 3

Хотя представления на основе классов полезны, наследование может не подходить для этой конкретной работы. Вспомогательные функции и декораторы - это два отличных способа отделить общий код от ваших представлений. Они также, как правило, более знакомы / естественны для других (python) кодеров, которые могут работать над вашим кодом.

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

p.s. слава за поиск питонического решения.

Answer 4

Оставляя в стороне другие проблемы (такие как проблемы безопасности потоков), создается впечатление, что здесь существует реальная опасность пересечь яркие линии между моделью / видом / шаблоном.

Или, может быть, это похоже на замену рассылки url ( не то, что с этим :-) что-то не так. Я не уверен, но он просто чувствует себя немного off .