Một số ý kiến về View của Django

Bài ghi chép gốc https://manhhomienbienthuy.github.io/2017/03/23/django-views-mot-vai-cam-nhan.html (đã van lơn quy tắc người sáng tác )

Django là một trong framework cực kỳ có tiếng, uy lực với thật nhiều tác dụng được ghi chép bên trên ngôn từ Python. Có nhiều nguyên nhân khiến cho nó trở thanh framework thông dụng như thế. Trong nội dung bài viết này, tôi tiếp tục trình diễn một vài ba chủ ý cá thể với phần Views của chính nó.

Bạn đang xem: Một số ý kiến về View của Django

Trước Lúc tất cả chúng ta chính thức, chúng ta nên mò mẫm hiểu qua chuyện một chút ít về framework này ở trên đây. Một chút nắm rõ chắc chắn về Python cũng khiến cho bạn làm rõ rộng lớn yếu tố.

Django dùng quy mô MVT (model-view-template)

Django được rất nhiều tư liệu, nhất là Django Book ra mắt rằng nó dùng quy mô MVC (model-view-controller). Mô hình này vô nằm trong không xa lạ rồi, có lẽ rằng tôi ko cần thiết thưa gì thêm thắt về nó. Một hình hình họa minh họa mang lại quy mô MVC như sau:

Thế tuy nhiên Lúc thao tác với Django, nhất là lúc tôi vẫn thao tác với Ruby on Rails rồi thì MVC của Django trái khoáy thực cực kỳ không giống những gì tôi nghĩ về. Và quy mô đúng đắn tuy nhiên Django xây dựng được gọi là MVT (model-view-template). Mô hình này như sau:

Phải chăng Django vẫn gọi sai thương hiệu, bọn họ gọi controller là view và gọi view là template. Theo giải thích của Django thì tất cả thú vị rộng lớn thật nhiều.

Django gọi quy mô mà người ta dùng là MVT cũng chính vì bạn dạng thân ái framework đó là controller (mà phần này thì vô xuyên suốt với những người dùng). Lý bởi cực kỳ giản dị, cũng chính vì framework đó là loại dùng để làm tinh chỉnh và điều khiển toàn cỗ framework, bao hàm cả model, template, view nhằm xử lý truy vấn và trả thành quả cho những người sử dụng.

Chúng tớ hiểu được, MVC là một trong quy mô cộng đồng mang lại toàn cỗ toàn bộ những ứng dụng chứ không cần nên là quy mô riêng biệt cho những phần mềm Web. Việc từng người dân có một con kiến giải không giống nhau hao hao cơ hội xây dựng không giống nhau mang lại quy mô này cũng là vấn đề dễ nắm bắt. Qua trên đây, tất cả chúng ta nhận thêm thời cơ hiển thêm thắt về quy mô MVC tưởng chừng như cực kỳ không xa lạ này.

Theo cơ hội xây dựng của Django, view tiếp tục thể hiện tại tài liệu trả về cho những người sử dụng, nó không chỉ có là cơ hội hiển thị tài liệu thế nào, tuy nhiên còn là một những tài liệu này được hiển thị nữa.

Ngược lại, Ruby on Rails và nhiều framework không giống kí thác trách nhiệm mang lại controller tiếp tục lấy tài liệu trả về cho những người sử dụng, trong những lúc view chỉ từ giản dị là hiển thị bọn chúng.

Mô hình MVC và được cách tân và phát triển vô thời hạn cực kỳ nhiều năm, và nó càng cách tân và phát triển mạnh không chỉ có thế vô thời đại Internet, Lúc tuy nhiên những phần mềm Web càng ngày càng thông dụng. Internet đó là một điểm hoàn hảo nhằm xây dựng quy mô client-server. Phần rộng lớn những framework trang web đều được thiết kế kể từ quy mô MVC. Và tôi bạo dạn Dự kiến rằng, nếu khách hàng đang xuất hiện ý muốn ko dùng MVC mang lại phần mềm Web của tớ, tài năng tối đa là chúng ta vẫn sai ngay lập tức kể từ phát minh.

Về mặt mũi định nghĩa, quy mô MVC cực kỳ đơn giản:

• Model (M) là tế bào phỏng của tài liệu. Nó ko thực sự là tài liệu, tuy nhiên nó là một trong thể hiện tại của tài liệu và là điểm nhằm tất cả chúng ta thao tác với tài liệu thiệt sự. Model được cho phép tất cả chúng ta lưu tài liệu vô DB và ko cần thiết hiểu những hoạt động và sinh hoạt sâu sắc xa vời bên dưới. Hơn nữa, model cung ứng mang lại tất cả chúng ta phương pháp thao tác với DB cực kỳ giản dị, làm cho một model hoàn toàn có thể dùng với thật nhiều DB không giống nhau.
• View (V) là tất cả những gì người tiêu dùng nhận ra. Nó là sự việc thể hiện tại của tài liệu so với người tiêu dùng. Nói một cơ hội văn vẻ, nó là sự việc thể hiện tại của Model. Trong phần mềm Web, nó đó là những gì người tiêu dùng nhận ra bên trên trình duyệt. Với phần mềm không giống, nó là tất cả những gì bọn họ nhận ra bên trên skin của phần mềm. Dường như, View còn cung ứng mang lại tất cả chúng ta cách thức nhằm tích lũy tài liệu kể từ người tiêu dùng.
• Controller (C) dùng để làm tinh chỉnh và điều khiển luồng vấn đề dữ Model và View. Nó được dùng nhằm thiết lập những login về sự việc lấy tài liệu kể từ DB trải qua Model và đem sang trọng View. Nó cũng chính là điểm xử lý những truy vấn kể từ người tiêu dùng trải qua View và triển khai những logic khác: thay cho thay đổi View, update tài liệu trải qua Model.

Bởi vì thế quy mô là một trong định nghĩa, nó hoàn toàn có thể được xây dựng cực kỳ không giống nhau trong số những framework không giống nhau. Những "Guru" của framework ê mới mẻ là kẻ biết đúng đắn bọn họ đang được xây dựng thế nào, và tác dụng này thuộc sở hữu Controller, tác dụng này thuộc sở hữu View.

Thực đi ra với những người dân thiết kế phần mềm như tất cả chúng ta, tất cả chúng ta chỉ dùng framework thì việc nắm rõ kỹ lưỡng về kiểu cách xây dựng của framework nhiều lúc không cần thiết lắm. Miễn là tất cả chúng ta vẫn nắm rõ framework ê, tất cả chúng ta tiếp tục hoàn toàn có thể hoàn thành xong được việc làm của tớ. Tất nhiên là nếu như với nắm rõ thì vẫn rộng lớn, nhất là lúc phỏng vấn ứng tuyển chọn.

Quay quay về với Django, nó trọn vẹn tuân theo đuổi quy mô MVC tuy nhiên cơ hội xây dựng của chính nó tương đối "dị". Bởi vì thế "C" đó là bạn dạng thân ái framework, và phần rộng lớn những thiết kế viên chỉ thao tác với Model, Template và View, nên Django thông thường được hiểu là dùng quy mô MVT. Trong quy mô này:

• Model (M) là lớp nhằm truy vấn tài liệu. Đây là điểm chứa chấp tất cả tương quan cho tới dữ liệu: phương pháp truy vấn DB, validate tài liệu, những cách thức và hành động của tài liệu, quan hệ của tài liệu.
• Template (T) là lớp hiển thị. Đây là điểm tiềm ẩn những gì tương quan cho tới việc hiển thị tài liệu cho những người dùng: tài liệu được hiện trên Web hoặc dạng thức này không giống.
• View (V) là điểm chứa chấp những logic. Lớp này chứa chấp những logic nhằm truy vấn tài liệu qua chuyện Model và truyền nó ra phía bên ngoài mang lại Template ứng. Nó hoàn toàn có thể xem như là một cầu nối lưu giữ Model và Template.

Mọi sự khó khăn hiểu cũng ra mắt ở trên đây Lúc View của Django đang được phụ trách tầm quan trọng tương tự động Controller vô MVC Lúc tuy nhiên nó có không ít logic. Sự khó khăn hiểu nhẹ nhõm này đơn giản thông thoáng qua chuyện Lúc tất cả chúng ta vẫn quen thuộc với những framework không giống. Rồi từng chuyện tiếp tục trở thành thông thường Lúc tất cả chúng ta lại quen thuộc với Django

View: class-based vs function-based, lợi và hại

Tôi nghe biết Django khá muộn. Không rõ ràng lịch sử vẻ vang thế này, tuy nhiên Lúc tôi nghe biết nó thì nó vẫn đối với tất cả class-based View và function-based View rồi. Function-based View là loại tôi nghe biết trước, còn class-based View thì nên mãi sau đây mới mẻ biết.

Khi mới mẻ nghe biết function-based View, nó là một trong loại cực kỳ giản dị. Mọi loại đều được thể hiện tại ở code. Tôi cần thiết gì, tôi code loại ê. Nhưng từ từ, Lúc việc trở thành phức tạp rộng lớn, những tác dụng tương tự động nhau xuất hiện tại nhiều hơn thế nữa, function-based View lại lòi ra lỗi của chính nó. Nó ko thể không ngừng mở rộng hao hao sử dụng lại được. Mỗi View tôi nên code một hàm, tuy nhiên nhiều phần cũng tương đối tương đương.

Có thể tôi ko nên là một trong thiết kế viên đầy đủ chất lượng tốt nhằm hoàn toàn có thể tái ngắt dùng những hàm. Nhưng rồi, class-based View đã hỗ trợ tôi.

Xem thêm: Cái váy ngủ tiếng anh là gì và đọc như thế nào cho đúng

Class-based view

Như vẫn thưa phía trên, class-based View được sinh đi ra sẽ giúp thiết kế viên đơn giản không ngừng mở rộng và tái ngắt dùng code. Lợi ích lớn số 1 của class-based View là nó hoàn toàn có thể thừa kế. Từ một View này, đơn giản tất cả chúng ta thiết kế View không giống chỉ với cùng một vài ba dòng sản phẩm code.

Hãy kiểm tra một ví như sau:

# urls.py
urlpatterns = [
    url(r'^user/(?P<pk>\d+)/$', UserDetailView.as_view(), name="user_view"),
]

# views.py
class UserDetailView(DetailView):
    model = User

    def get_context_data(self):
        context = super().get_context_data()
        context['posts'] = self.object.posts.all()
        return context

Vậy là tất cả chúng ta vẫn hoàn toàn có thể kéo ra được tài liệu và đem mang lại Template nhằm hiển thị cho những người sử dụng.

Như code phía trên, View của tất cả chúng ta vẫn dùng thừa kế. Thay vì thế code lại toàn cỗ View, tôi chỉ việc thừa kế nó từ 1 View không giống và thêm 1 vài ba sửa đổi là đầy đủ.

Ngoài đi ra, Django vẫn thiết kế sẵn thật nhiều View class mang lại những tác vụ thường thì của một phần mềm Web, ví như thêm thắt, sửa, xóa một đối tượng người tiêu dùng, list những đối tượng người tiêu dùng, phân trang, v.v...

Sử dụng những class View này sẽ hỗ trợ tất cả chúng ta tiết kiệm ngân sách thật nhiều thời hạn và sức lực nhằm thiết kế View mang lại phần mềm.

Bạn hoàn toàn có thể tìm hiểu thêm thêm thắt trang ccbv.co.uk, nó cung ứng vấn đề cực kỳ rất đầy đủ về những class View của Django. Một điều nữa là trang này cũng dùng class-based View nhằm thiết kế.

Tiếp tục với class-based View, nếu khách hàng nhằm ý, chúng ta có thể thấy rằng, thực đi ra nó cũng chính là function Lúc được gọi. Khi tất cả chúng ta thêm nữa URL, tất cả chúng ta dùng cách thức as_view(), nó sẽ bị trả về một function. Nội dung của hàm as_view như sau:

class View(object):
    ...

    @classonlymethod
    def as_view(cls, **initkwargs):
        """
        Main entry point for a request-response process.
        """
        for key in initkwargs:
            if key in cls.http_method_names:
                raise TypeError("You tried đồ sộ pass in the %s method name as a "
                                "keyword argument đồ sộ %s(). Don't bởi that."
                                % (key, cls.__name__))
            if not hasattr(cls, key):
                raise TypeError("%s() received an invalid từ khoá %r. as_view "
                                "only accepts arguments that are already "
                                "attributes of the class." % (cls.__name__, key))

        def view(request, *args, **kwargs):
            self = cls(**initkwargs)
            if hasattr(self, 'get') and not hasattr(self, 'head'):
                self.head = self.get
            self.request = request
            self.args = args
            self.kwargs = kwargs
            return self.dispatch(request, *args, **kwargs)
        view.view_class = cls
        view.view_initkwargs = initkwargs

        # take name and docstring from class
        update_wrapper(view, cls, updated=())

        # and possible attributes mix by decorators
        # lượt thích csrf_exempt from dispatch
        update_wrapper(view, cls.dispatch, assigned=())
        return view
    ...

Nội dung của tệp tin này khá nhiều năm, chúng ta có thể coi bạn dạng rất đầy đủ ở Github.

Hàm view được trả về vày as_view được xem là phần được dùng của từng class-based View. Khi được gọi, việc làm của chính nó là dùng dispatch nhằm xử lý truy vấn kể từ người tiêu dùng và gọi cho tới những hàm xử lý ứng. Ví dụ Lúc truy vấn vày GET thì tiếp tục gọi cách thức get, truy vấn POST tiếp tục gọi cách thức post, v.v...

Ưu điểm:

• Dễ dàng không ngừng mở rộng, tái ngắt dùng code (nhờ tài năng thừa kế tuyệt vời)
• Có thể thiết kế phía đối tượng người tiêu dùng đơn giản (View thừa kế nhiều class)
• Xử lý truy vấn HTTP riêng biệt ứng với từng cách thức GET, POST, v.v...
• Django thiết kế sẵn nhiều class cho những tác vụ thường thì, thời hạn code tiếp tục sụt giảm xứng đáng kể

Nhược điểm:

• Rất khó khăn nhằm hiểu code, vì thế việc thừa kế khiến cho những class View chỉ từ cực kỳ không nhiều code.
• Luồng tài liệu ko tường minh, vày dùng những class loại thừa kế khiến cho nhiều xử lý ko được thể hiện tại bên trên code.
• Những class được thiết kế sẵn là vô xuyên suốt với người tiêu dùng, cực kỳ khó khăn debug.
• Các xử lý phức tạp cần thiết ghi đè cách thức, hoặc dùng những decorators (yêu cầu import kể từ mặt mũi ngoài)

Function-based View

Ngược lại với class-based View, function-based View dễ nắm bắt rộng lớn thật nhiều. Tất cả những gì tất cả chúng ta mong muốn, tất cả chúng ta cần thiết code đi ra. Việc xử lý những truy vấn với cách thức không giống nhau hoàn toàn có thể triển khai như sau:

# urls.py
urlpatterns = [
    url(r'^user/(?P<pk>\d+)/$', view.user_view, name="user_view"),
]

# views.py
def user_view(request):
    if request.method == 'POST':
        # Code mang lại POST request
    else:
        # Code mang lại GET request
    # cũng có thể tiếp tục cần thiết thêm thắt code cho những cách thức khác ví như PATCH, DELETE

Function-based View ko cho mình lựa lựa chọn này không giống ngoài những việc nên ghi chép một hàm (có thể gọi hàm khác) nhằm xử lý những truy vấn. Lúc đầu tôi cực kỳ mến việc này, nó trọn vẹn không xẩy ra bó buộc. Mọi xử lý tôi cần thiết đều theo như đúng ý bản thân. Thế tuy nhiên việc nên ghi chép một hàm nhằm hiển thị khuông, tiếp sau đó validate tài liệu người tiêu dùng nhập vô rồi lưu tài liệu ê vô DB trái khoáy thực là cực kỳ gian khổ. Việc dùng class-based View kèm cặp với cùng một class Form sẽ hỗ trợ tất cả chúng ta thật nhiều thao tác.

Thế tuy nhiên, một vài tình huống như sau, function-based View lại là một trong lựa lựa chọn đơn giản rộng lớn class-based View

• Cần thao tác với khá nhiều model một khi. hầu hết Lúc tất cả chúng ta cần thiết thao tác với nhị hoặc nhiều model rộng lớn vô nằm trong 1 trang. Rõ ràng những class Django design ko nên mang lại tình huống này. Cố dùng class-based View với những loại mixin khiến cho tất cả chúng ta mất không ít thời hạn nhằm mò mẫm xử trí.
• Cùng 1 View tuy nhiên nên xử lý nhiều thao một khi. Đây là một trong điều rất dễ dàng gặp gỡ với những phần mềm Web bởi và một trang cần thiết thể hiện tại nhiều vấn đề cùng theo với những nút nhấn thời gian nhanh cho những người sử dụng dễ dàng thao tác.
• Edit bên trên điểm. Tại trên đây thông thường là tiếp tục nên dùng một vài nghệ thuật như AJAX nhằm gửi vấn đề người tiêu dùng nhập vô. Nó ko nên là một trong View với khuông và những input rõ nét nhằm submit Theo phong cách thường thì. Đây là một trong tình huống khó khăn và những class View được Django thiết kế sẵn ko tính cho tới.

Như vậy, function-based View cũng đều có những quyền lợi chắc chắn và vì thế, cả class-based View và function-based View đều đang được tồn bên trên tuy vậy tuy vậy.

Ưu điểm:

Xem thêm: *#06# là gì ? Tại sao * # 06 # được sử dụng để kiểm tra IMEI của điện thoại? - Nhanh như Chớp

• Dễ dàng thiết lập, cần thiết gì code nấy
• Code dễ dàng dọc, bởi tất cả đều thể hiện tại trong một function
• Luồng tài liệu tường minh
• Sử dụng decorators cực kỳ đơn giản

Nhược điểm:

• Khó không ngừng mở rộng và tái ngắt dùng code
• Tự phải ghi nhận tay xử lý riêng biệt cho những cách thức HTTP không giống nhau

Rõ ràng là, cả class-based View và function-based View đều sở hữu những điểm lợi và sợ hãi riêng biệt. Chẳng với dòng sản phẩm này chất lượng tốt rộng lớn dòng sản phẩm này, chỉ mất dòng sản phẩm này phù phù hợp với việc rộng lớn tuy nhiên thôi. Ví dụ, nếu khách hàng có nhu cầu các thao tác "tiêu chuẩn" với cùng một phần mềm Web như index, view, edit thì class-based View đó là loại chúng ta nên lựa lựa chọn. Nhưng nếu khách hàng có nhu cầu các thao tác xử lý phức tạp với thật nhiều loại tài liệu không giống nhau, function-based view mới mẻ là lựa lựa chọn phù hợp.

Kết luận

Django là một trong framework tuyệt hảo. Nó được cho phép tất cả chúng ta dùng những khí cụ đã có sẵn hao hao tự động ghi chép những gì mình đang có nhu cầu muốn. Điều ở đầu cuối tôi mong muốn thưa là, các bạn hãy mò mẫm hiểu về những class View tuy nhiên Django vẫn thiết kế sẵn tuy nhiên dùng bọn chúng vô phần mềm của khách hàng nếu như hoàn toàn có thể. Khi chúng ta đang khiến một thao tác xử lý thông thường, hãy dùng class-based View, nếu khách hàng cảm nhận thấy trở ngại lúc không biết nên lựa chọn class này nhằm thừa kế, này là khi chúng ta nên nghĩ về nên function-based View.