Câu hỏi Lợi thế của chế độ xem dựa trên lớp học là gì?


Tôi đọc ngày hôm nay rằng Django 1,3 alpha đang được vận chuyển và tính năng mới được chào hàng nhiều nhất là phần giới thiệu lượt xem dựa trên lớp học.
Tôi đã đọc tài liệu liên quan, nhưng tôi thấy khó thấy lợi thế lớn mà tôi có thể nhận được bằng cách sử dụng chúng, vì vậy tôi yêu cầu ở đây để được giúp đỡ trong việc hiểu chúng.
Hãy lấy một ví dụ nâng cao từ tài liệu.

urls.py

from books.views import PublisherBookListView

urlpatterns = patterns('',
    (r'^books/(\w+)/$', PublisherBookListView.as_view()),
)

views.py

from django.shortcuts import get_object_or_404
from django.views.generic import ListView
from books.models import Book, Publisher

class PublisherBookListView(ListView):

    context_object_name = "book_list"
    template_name = "books/books_by_publisher.html",

    def get_queryset(self):
        self.publisher = get_object_or_404(Publisher, name__iexact=self.args[0])
        return Book.objects.filter(publisher=self.publisher)

    def get_context_data(self, **kwargs):
        # Call the base implementation first to get a context
        context = super(PublisherBookListView, self).get_context_data(**kwargs)
        # Add in the publisher
        context['publisher'] = self.publisher
        return context

Và bây giờ chúng ta hãy so sánh nó với một giải pháp "đồng bằng cũ", được thực hiện bởi bản thân mình trong 5 phút cho câu hỏi này (Tôi xin lỗi vì bất kỳ lỗi nào bạn có thể tìm thấy trong đó).

urls.py

urlpatterns = patterns('books.views',
    url(r'^books/(\w+)/$', 'publisher_books_list', name="publisher_books_list"),
)

views.py

from django.shortcuts import get_object_or_404
from books.models import Book, Publisher

def publisher_books_list(request, publisher_name):
    publisher = get_object_or_404(Publisher, name__iexact=publisher_name)
    book_list = Book.objects.filter(publisher=publisher)

    return render_to_response('books/books_by_publisher.html', {
        "book_list": book_list,
        "publisher": publisher,
    }, context_instance=RequestContext(request))

Phiên bản thứ hai cho tôi trông:

  • Tương đương chức năng
  • Rất dễ đọc hơn (self.args[0]? kinh khủng!)
  • Ngắn hơn
  • Không ít tuân thủ DRY

Có cái gì đó lớn tôi đang mất tích? Tại sao tôi nên sử dụng chúng? Là những người trên tài liệu? Nếu vậy thì trường hợp sử dụng lý tưởng là gì? Là mixins hữu ích?

Cảm ơn trước cho bất kỳ ai đóng góp!

P.S. đối với những người có thể thắc mắc, tôi không bao giờ bị mê hoặc bởi quan điểm chung: ngay sau khi tôi cần một số chức năng nâng cao, chúng trở nên không ngắn hơn so với lượt xem thông thường.


76
2017-12-06 20:29


gốc


Tôi cũng không thấy lợi thế lớn. Rất thích nhìn thấy một câu trả lời lớn về điều này. - M. Ryan
Hoàn toàn đồng ý. Tôi đặc biệt ghê tởm bởi self.args [0] hoặc self.kwargs ['slug']. Bây giờ cũng khó hơn rất nhiều để cung cấp các giá trị mặc định cho các tham số url, như sau: def publisher_books_list (request, publisher_name = 'Herbert') - Kevin Renskers


Các câu trả lời:


Bạn có thể phân lớp một lớp và tinh chỉnh các phương thức như get_context_data cho các trường hợp cụ thể và để nguyên các phần còn lại. Bạn không thể làm điều đó với các chức năng.

Ví dụ, bạn có thể cần phải tạo một khung nhìn mới để thực hiện mọi thứ mà trước đó làm, nhưng bạn cần bao gồm các biến phụ trong ngữ cảnh. Phân lớp chế độ xem gốc và ghi đè phương thức get_context_data.

Ngoài ra, việc tách các bước cần thiết để hiển thị mẫu thành các phương thức riêng biệt thúc đẩy mã rõ ràng hơn - ít được thực hiện hơn trong một phương thức, dễ hiểu hơn. Với chức năng xem thông thường, tất cả được đổ vào một đơn vị xử lý.


46
2017-12-07 04:19



Vâng, tôi có thể thấy điều này. Nó làm cho một cách dễ dàng ghi đè, và thường xuyên pha trộn trong, trường hợp khi cố gắng để quyết định xem bạn nên đi RESTful, có một trang web đầy đủ, hoặc một trang web di động. Với điều này, quyết định đó có thể được đưa ra càng lâu càng tốt trong khi chức năng được bắt nguồn. Các mô-đun phần mềm Web trong giá treo có điều này, và nó rất hữu ích. Điều đó nói rằng, quan điểm dựa trên lớp học từ lâu đã có thể với Django bằng cách ghi đè phương thức __call __ (). - Elf Sternberg
Chấp nhận câu trả lời vì nó cung cấp một điểm rất tốt ... nhưng vẫn không cảm thấy cần phải sử dụng chúng, vì tôi hiếm khi có những vấn đề như vậy để giải quyết. Cảm ơn! - Agos


Nếu self.args[0] đang làm phiền bạn, thay thế là:

urlpatterns = patterns('books.views',
    url(r'^books/(?P<slug>\w+)/$', 'publisher_books_list', name="publisher_books_list"),
)

Sau đó, bạn có thể sử dụng self.kwargs['slug'] thay vào đó, làm cho nó dễ đọc hơn một chút.


16
2018-01-21 15:45





Hàm ví dụ và lớp của bạn không bằng nhau trong các tính năng.

Phiên bản dựa trên lớp cung cấp phân trang miễn phí và cấm sử dụng các động từ HTTP khác so với GET.

Nếu bạn muốn thêm điều này vào chức năng của bạn, nó sẽ lâu hơn nhiều.

Nhưng nó thực sự phức tạp hơn.


10
2018-03-25 13:41



1 để chỉ sự khác biệt, nhưng cá nhân tôi nghĩ rằng require_GET và django-pagination là tầm thường để sử dụng, ngắn gọn, rõ ràng, vv và tôi thích họ để cbvs tại (gần như :)) tất cả các lần. - Tomasz Zielinski


Đây là lần đầu tiên tôi nghe về điều này - và tôi thích nó.

Lợi thế tôi thấy ở đây, trung thực, là nó làm cho quan điểm phù hợp hơn với Django tổng thể. Mô hình là các lớp học và tôi luôn cảm thấy rằng lượt xem cũng vậy. Tôi biết không phải tất cả mọi thứ là nhưng quan điểm và mô hình là hai được sử dụng nhiều các loại.

Đối với lợi thế kỹ thuật? Vâng, trong Python mọi thứ đều là một lớp (hoặc đối tượng?) - Vì vậy, có thực sự là một sự khác biệt? Không phải là 99% đường cú pháp ở nơi đầu tiên sao?


4
2017-12-06 20:36



Tôi sẽ nói rằng sự nhất quán cho phép tái sử dụng mã lớn hơn. Họ về cơ bản cắt giảm rất nhiều boilerplate, nếu quan điểm của bạn phù hợp với mô hình nhất định. ví dụ: một biểu mẫu dựa trên mô hình cực kỳ nhanh chóng tạo ra với chế độ xem dựa trên lớp học. Nếu nó cần thêm một vài trường, nó bắt đầu trở nên phức tạp hơn một chút. Nếu bạn cần một hình thức dựa trên ba mô hình cộng với hai lĩnh vực phụ, họ có thể sẽ không giúp bạn tiết kiệm nhiều nỗ lực cả. - wobbily_col


Một cách để suy nghĩ về lớp học dựa trên quan điểm, là họ giống như một quản trị Django với bánh xe đào tạo tắt và do đó rất nhiều linh hoạt hơn (nhưng khó hiểu hơn).

Ví dụ danh sách hiển thị trong quản trị viên rõ ràng dựa trên ListView chung. Chế độ xem danh sách đơn giản nhất bạn sẽ chỉ xác định mô hình hoặc bộ truy vấn.

class MyExampleView(ListView);
    model = ExampleModel 

Bạn sẽ cần phải cung cấp mẫu của riêng bạn, nhưng về cơ bản nó sẽ giống như ModelAdmin cơ bản nhất. Thuộc tính list_display trong mô hình quản trị viên sẽ cho nó biết những gì các lĩnh vực để hiển thị, trong khi trong ListView bạn sẽ làm điều này trong mẫu.

class SpeciesAdmin(admin.ModelAdmin):
    list_display = ['name']
admin.site.register(ExampleModel , ExampleModelAdmin)

Với quản trị viên, bạn có thông số

list_per_page = 100

xác định số lượng đối tượng trên mỗi trang. Chế độ xem danh sách có

paginate_by = 100

mà đạt được điều tương tự. Tương tự như vậy nếu bạn nhìn vào tùy biến admin rất nhiều, bạn sẽ thấy rất nhiều sự chồng chéo.

Trang web này ở đây sẽ cung cấp cho bạn một ý tưởng tốt hơn về những gì họ làm là tốt.

http://ccbv.co.uk/


1
2018-03-19 14:16