邁入Day27!

今天不說更深入的內容，來講點古吧!

在這段時間，我們從最一開始的FBV - Function-Based View，講到了更方便開發的 CBV - Class-Based View

小弟我一開始邁入 CBV 的當下，除了看教學直接使用，見識它的強大之外，更是激起了我對 CBV 的求知慾

而當下我就在想，感覺就是會有 CBV 及 FBV 兩派的支持者，於是我就去 google 了，果然不出我所料

讓我們看看 Vitor Fretas 怎麼說

對於小弟我而言...，第一次接觸的就是 Django 2.1，雖然這段時間在找資料的時候也有發現 Django 2 & 1 之間的差異性，但如果要討論到 CBV...

就要追朔到 Django 1.3! 因為 Django CBV 是在 1.3版之後才推出的，那麼也就是說老一輩的前輩們都是運用著 FBV在操作邏輯

在我第一次接觸 FBV，讓我覺得 : WOW，這寫法怎麼這麼簡單，就可以達到我的目的

• 簡單
• 容易理解
• 直觀

這三點就夠足以凸顯 FBV 的特色了，但相對的，寫了這麼多的 FBV，慢慢你會發覺都是在做這些事情

1. 根據 request 決定邏輯
2. 做處理 (get or create ...)
3. 回傳 context

程式碼演示 :

def vendor_create_view(request):
    form = RawVendorForm(request.POST or None)
    if form.is_valid(): # 決定邏輯
        Vendor.objects.create(form.cleaned_data) # 作處理
        form = RawVendorForm()
        # return redirect('/vendor/')
    context = {
        'form' : form
    }
    return render(request, "vendors/vendor_create.html", context) # 回傳空的表單

也因為重複性的作這件事情，所以才衍生出了 CBV

CBV 之所以會被大家稱讚，最主要的原因不外乎是因為 類別的延展性，這樣的特性也遵循著 DRY 的性質

雖然 CBV 提供了我們相當足夠的模板來完成事情，但這對於剛接觸 CBV 的 新手而言，真的是一個痛!
如果只是想作出非常簡易功能的網站，或許還能夠應付得來，但是當要開始客製化自己的功能時，勢必要去做覆寫的動作，然而往往悲劇就是從這一刻開始產生的

為了解決這個問題問題，除了上網找資料以外，也無可避免地要去看 Source Code 到底在搞什麼把戲，於是乎你會發現，這棵~~繼承樹好大顆~~

不過這些 one-time pain，只要結束之後，對於 master CBV 的路已經不遠了，只是這段痛持續的時間不會太短就是了^_^"

最後，究竟是 CBV 比較好還是 FBV比較好，這並沒有一個標準答案，要看需求來作決定

那這邊引用 Vitor Fretas提供的適合用在 CBV 及 FBV 的案例

• CBV : 你想要的功能在某一個CBV都提供了(e.g. ListView)，而你純粹覆寫一些屬性，CBV比較適合
• FBV : 同時處理多個表單，FBV比較適合!

最後是 Django Documentation 提到的一些建議

If you find you’re struggling to implement your view as a subclass of a generic view, then you may find it more effective to write just the code you need, using your own class-based or functional views.

今日小節

今天主要帶大家了解CBV及FBV各自的特色及使用時機，雖然沒有身處過純 FBV 的版本，但是它依舊在撰寫邏輯上能帶給我們相當大的幫助 ^^

今天就這樣，明天見~