Django開發(fā)方法是什么

這篇文章主要介紹“Django開發(fā)方法是什么”，在日常操作中，相信很多人在Django開發(fā)方法是什么問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”Django開發(fā)方法是什么”的疑惑有所幫助！接下來，請跟著小編一起來學(xué)習(xí)吧！

PART 1. 開始之前

Django作為一款功能強大的Web應(yīng)用框架，近年來逐步受到大家的歡迎，越來越多的Python開發(fā)者投入到Django的懷抱中，但是同樣由于Django中的眾多內(nèi)容，大家在初入Django時總會感到有一些『心有余而力不足』，不知道從何處下手?；蚴谴匠醪搅私夂螅恢喇?dāng)前的做法是否優(yōu)雅，不知道如何組織一個工程，如何去復(fù)用自己的代碼。

PART 2. 項目架構(gòu) 

好的項目結(jié)構(gòu)是成功的一半。

2.1 整體結(jié)構(gòu)

在默認(rèn)情況下，由Django生成的項目結(jié)構(gòu)大概是這樣的：

隨著項目中的Application不停的增加，本地根目錄下的package會不停的變多，導(dǎo)致越來越難維護，所以我們要對整個項目有一個清晰的規(guī)劃，合理的放置各個文件的位置。

如果項目較小，且不打算將其中的Application進行各種復(fù)用，可以考慮如下方式：

venv文件夾存放項目的virtualenv環(huán)境，非必須，可以放置在其他地方。

database這個App專門用于存放model、manage的命令以及模板中用到的一些自定義filters，存放在項目根目錄下。

docs和logs分別存放工程的相關(guān)文檔和運行時產(chǎn)生的log文件。

static存放靜態(tài)文件，例如css/js/img/font等。

utils存放工程中用到的工具函數(shù)、類，以及一些通用的模塊，例如logger等。

templates存放模板文件，父模板或被多個模板繼承的模板放在根目錄，并且以base之類的名稱命名，方便維護，其余的模板放在對應(yīng)的application名字的文件夾中。

web目錄存放所有的Application，如果有很多的Application，可以在此基礎(chǔ)上分成更多的package來規(guī)劃，每個package里存放一類的Application。

2.2 Model

在Model模塊部分，我們主要關(guān)心數(shù)據(jù)到類的映射，一般情況下，每張表對應(yīng)的類將放置在單獨的文件中，并在models/__init__.py中將對應(yīng)的類依次導(dǎo)入，這樣在其他地方使用時可以通過from database.models import xxxx導(dǎo)入，給類命名時建議添加上項目的名稱，例如我這里有個項目的名字是Cherry，那么所有的類均為CherryLeaks，CherryVulns等，在reivew代碼以及編寫的過程中會一目了然，知道這個類代表了數(shù)據(jù)。

如果有很多針對Models進行的重復(fù)操作，建議為當(dāng)前表添加單獨的manager，并且實現(xiàn)對應(yīng)的方法。

除此之外，還有一些建議，可以根據(jù)實際情況取舍：

不建議使用外鍵等類型

每張表添加is_deleted，created_time，updated_time字段

善用索引

2.3 View

View部分應(yīng)當(dāng)是最為核心的部分，大部分的業(yè)務(wù)邏輯應(yīng)該都在此處。這里也是推薦將功能相近的View全部放置在同一個文件中。并且放置在一個叫做controller或view的包中，方便以后的維護和開發(fā)。例如處理project相關(guān)的路由，全部放置在controller/project.py中。

優(yōu)先使用Django內(nèi)置的一些View類，例如ListView，TemplateView等，如果需要自己實現(xiàn)View的情況，推薦使用Class-based view，將不同的請求方法封裝到不同的方法中，方便日后維護。

2.4 Template

對于模板文件而言，最好的方法就是將不同的頁面、功能切割為不同的模板文件，并按Applicatio的名稱按文件夾存放，這樣在后期維護時，可以快速的從每個Application找到對應(yīng)的模板文件。

除此之外，強烈推薦使用模板的繼承功能，所有的頁面均從父模板繼承下來，并且使用各種block來擴充頁面，父模板中定義好每個位置的block名稱，供子模板覆蓋。建議使用通俗簡短的名稱為每個block命名，例如：sidebar，script，header，main_content，page_title，page_description等。

對于通用的功能，例如評論框，可以考慮單獨存放在一個文件中，在需要的地方通過{% include 'filename.tpl.html' %}加載進來。需要注意的是，如果你需要同時使用extends和include指令，一定要在block中使用，否則是無效的。如下例子是無效的：

應(yīng)當(dāng)按照如下方式使用：

PART 3. 代碼風(fēng)格  

3.1 docstring

由于Python語言過于靈活，很多時候我們寫著寫著就會忘記某些方法的參數(shù)類型，或是返回值類型。這個時候我們就需要docstring來將每個方法的信息標(biāo)注清晰，方便其他人的開發(fā)與維護。如果是使用的PyCharm，可以參考這個鏈接，編寫PyCharm可以自動補全docstring。

3.2 多返回值

很多情況下，我們的方法需要返回多個值給調(diào)用方，或者通過JSON返回給前端，如果胡亂的返回數(shù)據(jù)，就會導(dǎo)致開發(fā)混亂，到最后根本不知道方法返回了什么東西。

一個比較好的做法就是約定好返回的格式，對于返回給調(diào)用方而言，簡單的返回tuple即可，并在docstring中寫明每個值的含義。很多時候我們除了需要返回結(jié)果之外，還需要返回一個err來表示在處理數(shù)據(jù)的過程中是否出現(xiàn)問題或異常。一般情況下有幾種可用的方法：

通過raise拋出異常

通過多返回值返回，例如err, result = func()

通過類中的一個屬性返回，例如instance = Class(); err = instance.error_message

這三種方法均有利弊，需要根據(jù)項目的實際情況來選取，無論使用哪一種方法，都需要在整個項目中保持統(tǒng)一，盡可能的不要混合使用；

對于返回給前端的JSON，就需要稍微復(fù)雜一些，至少要返回2~3個字段：

code是本次調(diào)用返回的狀態(tài)碼，根據(jù)實際情況自行約定。message是狀態(tài)碼的可讀信息，用于開發(fā)人員調(diào)試或是通知用戶。data是實際返回的數(shù)據(jù)信息，很多時候可以不需要這個字段，具體的字段格式也需要根據(jù)實際情況再次進行約定。

PART 4. 路由組織  

優(yōu)雅簡單的路由保證項目質(zhì)量，降低維護成本。

4.1 路由系統(tǒng)

Django有一套強大的路由系統(tǒng)以及路由算法，可以滿足業(yè)務(wù)中的各種需要，并且配置靈活簡單，每一個路由配置文件都是URL PATH到function/class的映射。全部都可以自己設(shè)置，完全不會受到框架或是其他的一些限制。關(guān)于Django處理請求時的路由尋找策略可以參考文檔中的這個部分。

在配置路由中，你可以用尖括號括起來一些變量，便于在后面使用。尖括號里可以用一些"路徑轉(zhuǎn)換器（Path Converters）"來指定變量類型，例如str, int, slug, uuid, path。一個完整的URL路由文件看起來像下面這樣：

除此之外，還可以通過re_path在路由中設(shè)置正則匹配：

有些時候，你可能希望為一些URL添加一個默認(rèn)路由，例如訪問/blog/的時候返回一個默認(rèn)頁面，而訪問/blog/page<int:num>的時候返回指定頁碼的內(nèi)容，可以通過如下方式配置

4.2 路由包含

隨著項目的不斷擴大，用到的路由也會不斷的變多，所以Django提供了路由包含的機制，便于我們在不同的App中組織路由。我們來看一個簡單的例子：

這個例子中，將所有請求community/*的路由全部交由aggregator.urls去解析，同理，contact/*的請求也全部交給了另外的路由模塊去處理；如果你的項目中并沒有這么多的Application，依然想通過include的方式來管理路由，那么可以采用如下方式：

4.3 命名空間

一般情況下，我們的每個Django項目都由多個App組成，如果把所有App的路由全部放在URLCONF_ROOT里，時間久了這個文件會變的越來越難維護，十分混亂。并且，不同的App中可能會用到相同命名的路由，會產(chǎn)生沖突的情況。為了解決這些問題，我們可以通過使用"路由包含"和"命名空間"來解決，特別是如果你在維護一個可以被復(fù)用的App，為了保證路由的唯一，命名空間就顯得尤為重要了。

命名空間通常有兩種：Application namespace和Instance namespace，例如admin:index表示admin命名空間的index路由。更多關(guān)于該部分的內(nèi)容可以參考：官方文檔

Application Namespace比較好理解，指的是在應(yīng)用程序?qū)用嫔系拿臻g，一般是如下方式組織的：

Instance Namespace則指的是實例級別的命名空間，常用于一個App被多次實例化的情況，為了區(qū)分每個實例，就需要引入Instance Namespace。我們使用官方文檔中的例子看一下：

可以看到兩個路由author-polls和publisher-polls其實都包含了相同的路由，但是指定了不同的命名空間，這就是Instance級別的命名空間，即當(dāng)前正在訪問的對象的命名空間。不同的用戶身份訪問不同的URL，會得到不同的命名空間，例如游客和管理員均訪問polls:index所指向的頁面，但是由于命名空間的不同，會得到完全不同的結(jié)果。

到此，關(guān)于“Django開發(fā)方法是什么”的學(xué)習(xí)就結(jié)束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學(xué)習(xí)，快去試試吧！若想繼續(xù)學(xué)習(xí)更多相關(guān)知識，請繼續(xù)關(guān)注億速云網(wǎng)站，小編會繼續(xù)努力為大家?guī)砀鄬嵱玫奈恼拢?/p>