Class-based views — зачем и как использовать

[@printf]

Удобно, когда нужно описать джва десятка почти одинаковых views. Еще я полюбил разделение HTTP GET / POST / DELETE в разные методы (еще до включения этой штуки в транк у меня был похожий фрагмент кода, реализующий именно это).

С другой стороны, использовать class-based views повсеместно, на мой взгляд, оверкилл. Функции проще и прозрачнее классов, их легче читать и отлаживать.

[@Zapix]

Ну а зачем, «плодить» похожие функции, если в них меняется только одно действие, обработка формы к примеру.
Да и отладить проще маленький метод, нежели вчитываться в большую функцию.

[@printf]

Если похожие, то да.

[@karantir]

С помощью class-based вы можете разбить выполнение вьюхи на логические блоки общие для всего проекта, разложив их по методам класса. Это позволяет очень удобно расширять функциональность в дочерних классах, используя super() и прочие прелести. Мixins опять же.

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

[@qmax]

А как именно вы рассовали get/post в разные методы?
А то вот я привык уже к такому по gae, а как соорудить в джанге что-то не соображу.

[@printf]

gist.github.com/1688557 вот такая штука, и от нее наследуется view.

[@Azy]

get_context разве не должна возвращать context?

[@Zapix]

он возвращает словарь, из которого формируется context.

[@Azy]

Я имел в виду переменную context, которая не возвращалась в методе. Уже исправили.

[@dufft]

Да, я прочел комментарий после того, как исправил сам. Спасибо.

[@savados]

1. Если метод нужно реализовывать в классе-наследнике, то нужно не `pass`, а `raise NotImplementedError`
2. Если вам нужно что-то сделать с queryset'ом, то это лучше делать в менеджере модели, а не во вьюхе.
3. Сериализация (в том числе и в JSON) уже есть в Джанге.

А еще смотрите, если вы решите использовать ваше `MixedView` для другой модели, то, вам придется написать:

class ArticleView(MixedView):
    def get_context(self, request): #!
        context = dict() #!
        context['articles'] =Article.objects.all()
        return context #!

    template_name = 'articles_list.html'

    def convert_context_to_json(self, context): #!
        json_context = dict() #!
        json_context['article_names'] = [p.name for p in context['articles']]
        return json.dumps(json_context, encoding='utf-8', ensure_ascii=False) #!

Восклицательными знаками я отметил строчки, которые придется копировать без изменений. Их 6 из 10! Просто anti-DRY. Можно, в качестве альтернативы, добавить еще один слой наследования и в конец запутать код.

Мне кажется, что CBV в 95% случаев не нужны. Хитросплетения методов и цепочек наследования намного сложнее поддерживать, чем функции. Они не гибкие (если вы используете ListView, а однажды вам понадобится вывести не один а два списка чего-то, что тогда?). Если у вас реально сложная иерархия вьюх в проекте, то может быть CBV и подойдут, но много ли таких проектов.

[@qmax]

Под «что-то делать с queryset-ом» вы имели ввиду [p.name for p in context['items']]?
Как это грамотно прикрутить к менеджеру модели?

[@savados]

Примерно так:

from django.core import serializers

class MyModelManager(models.Manager):
    def to_json(self):
        return serializers.serialize('json', self.all(), fields=('name',), ensure_ascii=False)

class MyModel(models.Model):
    # всякие поля тут
    # ...
    objects = MyModelManager()

Ну и затем вызывать MyModel.objects.to_json().

[@dufft]

Вот про нативную сериализацию я не знал, спасибо за подсказку. В таком случае можно написать общий сериализатор под все контексты, и опустить convert_context_to_json() вообще.

[@dufft]

За 1 и 3 большое спасибо, а 2 не понял. Какие именно действия с QuerySet'ом тут нужно перенести в менеджер? Это ведь нужно делать, если предполагается еще где-то использовать такой запрос?

> Если у вас реально сложная иерархия вьюх в проекте, то может быть CBV и подойдут, но много ли таких проектов.

Дело быть не только в сложной иерархии вьюх в одном проекте, но и в их использовании в других проектах. Хочется, чтобы код, написанный для одного проекта, был бы полезен в других. Это такой межпроектный DRY. Понятно, что создавая лишний уровень абстракции использованием наследования мы усложняем отладку и общее понимание кода, однако мы же выигрываем в астрагировании — программист пишущий MixedView, например, не должен будет задумываться о том, что и как сериализуется.

Мне нравится идея выделения отдельной части представления, ответственной за конечное преобразование данных в ответ. Потому что компоновка данных из базы, их предобработка по запросу — это отдельная задача, а преобразование запроса для просмотра в том или ином виде — совсем другая. И, как Вы подсказали, задача сериализации подготовленных для ответа данных в JSON, например, решается одинаково, независимо от вида этих данных.

[@savados]

По поводу 2, тут, скорее, дело вкуса (поэтому «лучше», а не «нужно» :-)), но во view этому коду точно не место. Можно в менеджер, можно в отдельный сериализатор. Даже если его предполагается использовать один раз, есть и другие причины. Например, чтобы протестировать, как работает сериализация, вам нужно «прогнать» view полностью, с контекстом, реквестом и прочим. Если вынести его куда-нибудь, тестирование становится приятным. Документировать код проще, глядя на менеджер, я сразу вижу, что он сериализуется в json, тут логика не так ясна. Сильное связывание опять же, получается, что я не могу сериализовать объект без атрибута name.

Плюс менеджеры не менее «реюзабельны», чем CBV, тот самый межпроектный DRY.

> Мне нравится идея выделения отдельной части представления, ответственной за конечное преобразование данных в ответ.
В вашем случае это HttpResponse(data, content_type='application/json'). Если очень необходимо это выделить, то почему бы не так?

[@zw0rk]

context=super(MyClassView, self).get_context_data() вместо context=dict() не лучше ли?

[@zw0rk]

тьфу, без _data

[@savados]

Это если у класса родителя есть такой метод, и он действительно возвращает dict-like объект. В данном случае это не так.

Но это хорошо показывает сложность поддержки CBV.

[@zw0rk]

Ну во всех «новых генериках», которые пришли на смену func-based-ам оно есть: в ListView, DetailView и прочих. Имхо, это стандартная практика, которую предлагает django-team.

[@savados]

В статье речь не о генериках, а о CBV в целом. У базового класса View этого метода нет.

[@alz]

CBV хороши для приложений, которые делаются для повторного использования. Сколько раз сталкивался: есть некое приложение, в нем вьюха, и хочется немного изменить ее поведение. И вот тут вьюхи на функциях предстают как черный ящик — на входе параметры, на выходе — HttpResponse, с которым уже мало что можно сделать. Хорошо, если автор предусмотрел какие-то параметры, с помощью которых можно кастомизировать поведению вьюхи. Иначе остается только переписывать весь ее код ради небольших изменений