這篇文章主要介紹“Django開發(fā)方法是什么”，在日常操作中，相信很多人在Django開發(fā)方法是什么問題上存在疑惑，小編查閱了各式資料，整理出簡(jiǎn)單好用的操作方法，希望對(duì)大家解答”Django開發(fā)方法是什么”的疑惑有所幫助！接下來，請(qǐng)跟著小編一起來學(xué)習(xí)吧！
目前成都創(chuàng)新互聯(lián)已為1000多家的企業(yè)提供了網(wǎng)站建設(shè)、域名、網(wǎng)站空間、網(wǎng)站托管運(yùn)營(yíng)、企業(yè)網(wǎng)站設(shè)計(jì)、呼圖壁網(wǎng)站維護(hù)等服務(wù)，公司將堅(jiān)持客戶導(dǎo)向、應(yīng)用為本的策略，正道將秉承"和諧、參與、激情"的文化，與客戶和合作伙伴齊心協(xié)力一起成長(zhǎng)，共同發(fā)展。
Django作為一款功能強(qiáng)大的Web應(yīng)用框架，近年來逐步受到大家的歡迎，越來越多的Python開發(fā)者投入到Django的懷抱中，但是同樣由于Django中的眾多內(nèi)容，大家在初入Django時(shí)總會(huì)感到有一些『心有余而力不足』，不知道從何處下手?；蚴谴匠醪搅私夂?，不知道當(dāng)前的做法是否優(yōu)雅，不知道如何組織一個(gè)工程，如何去復(fù)用自己的代碼。
好的項(xiàng)目結(jié)構(gòu)是成功的一半。
在默認(rèn)情況下，由Django生成的項(xiàng)目結(jié)構(gòu)大概是這樣的：
隨著項(xiàng)目中的Application不停的增加，本地根目錄下的package會(huì)不停的變多，導(dǎo)致越來越難維護(hù)，所以我們要對(duì)整個(gè)項(xiàng)目有一個(gè)清晰的規(guī)劃，合理的放置各個(gè)文件的位置。
如果項(xiàng)目較小，且不打算將其中的Application進(jìn)行各種復(fù)用，可以考慮如下方式：
venv文件夾存放項(xiàng)目的virtualenv環(huán)境，非必須，可以放置在其他地方。
database這個(gè)App專門用于存放model、manage的命令以及模板中用到的一些自定義filters，存放在項(xiàng)目根目錄下。
docs和logs分別存放工程的相關(guān)文檔和運(yùn)行時(shí)產(chǎn)生的log文件。
static存放靜態(tài)文件，例如css/js/img/font等。
utils存放工程中用到的工具函數(shù)、類，以及一些通用的模塊，例如logger等。
templates存放模板文件，父模板或被多個(gè)模板繼承的模板放在根目錄，并且以base之類的名稱命名，方便維護(hù)，其余的模板放在對(duì)應(yīng)的application名字的文件夾中。
web目錄存放所有的Application，如果有很多的Application，可以在此基礎(chǔ)上分成更多的package來規(guī)劃，每個(gè)package里存放一類的Application。
在Model模塊部分，我們主要關(guān)心數(shù)據(jù)到類的映射，一般情況下，每張表對(duì)應(yīng)的類將放置在單獨(dú)的文件中，并在models/__init__.py中將對(duì)應(yīng)的類依次導(dǎo)入，這樣在其他地方使用時(shí)可以通過from database.models import xxxx導(dǎo)入，給類命名時(shí)建議添加上項(xiàng)目的名稱，例如我這里有個(gè)項(xiàng)目的名字是Cherry，那么所有的類均為CherryLeaks，CherryVulns等，在reivew代碼以及編寫的過程中會(huì)一目了然，知道這個(gè)類代表了數(shù)據(jù)。
如果有很多針對(duì)Models進(jìn)行的重復(fù)操作，建議為當(dāng)前表添加單獨(dú)的manager，并且實(shí)現(xiàn)對(duì)應(yīng)的方法。
除此之外，還有一些建議，可以根據(jù)實(shí)際情況取舍：
不建議使用外鍵等類型
每張表添加is_deleted，created_time，updated_time字段
善用索引
View部分應(yīng)當(dāng)是最為核心的部分，大部分的業(yè)務(wù)邏輯應(yīng)該都在此處。這里也是推薦將功能相近的View全部放置在同一個(gè)文件中。并且放置在一個(gè)叫做controller或view的包中，方便以后的維護(hù)和開發(fā)。例如處理project相關(guān)的路由，全部放置在controller/project.py中。
優(yōu)先使用Django內(nèi)置的一些View類，例如ListView，TemplateView等，如果需要自己實(shí)現(xiàn)View的情況，推薦使用Class-based view，將不同的請(qǐng)求方法封裝到不同的方法中，方便日后維護(hù)。
對(duì)于模板文件而言，最好的方法就是將不同的頁(yè)面、功能切割為不同的模板文件，并按Applicatio的名稱按文件夾存放，這樣在后期維護(hù)時(shí)，可以快速的從每個(gè)Application找到對(duì)應(yīng)的模板文件。
除此之外，強(qiáng)烈推薦使用模板的繼承功能，所有的頁(yè)面均從父模板繼承下來，并且使用各種block來擴(kuò)充頁(yè)面，父模板中定義好每個(gè)位置的block名稱，供子模板覆蓋。建議使用通俗簡(jiǎn)短的名稱為每個(gè)block命名，例如：sidebar，script，header，main_content，page_title，page_description等。
對(duì)于通用的功能，例如評(píng)論框，可以考慮單獨(dú)存放在一個(gè)文件中，在需要的地方通過{% include 'filename.tpl.html' %}加載進(jìn)來。需要注意的是，如果你需要同時(shí)使用extends和include指令，一定要在block中使用，否則是無(wú)效的。如下例子是無(wú)效的：
應(yīng)當(dāng)按照如下方式使用：
由于Python語(yǔ)言過于靈活，很多時(shí)候我們寫著寫著就會(huì)忘記某些方法的參數(shù)類型，或是返回值類型。這個(gè)時(shí)候我們就需要docstring來將每個(gè)方法的信息標(biāo)注清晰，方便其他人的開發(fā)與維護(hù)。如果是使用的PyCharm，可以參考這個(gè)鏈接，編寫PyCharm可以自動(dòng)補(bǔ)全docstring。
很多情況下，我們的方法需要返回多個(gè)值給調(diào)用方，或者通過JSON返回給前端，如果胡亂的返回?cái)?shù)據(jù)，就會(huì)導(dǎo)致開發(fā)混亂，到最后根本不知道方法返回了什么東西。
一個(gè)比較好的做法就是約定好返回的格式，對(duì)于返回給調(diào)用方而言，簡(jiǎn)單的返回tuple即可，并在docstring中寫明每個(gè)值的含義。很多時(shí)候我們除了需要返回結(jié)果之外，還需要返回一個(gè)err來表示在處理數(shù)據(jù)的過程中是否出現(xiàn)問題或異常。一般情況下有幾種可用的方法：
通過raise拋出異常
通過多返回值返回，例如err, result = func()
通過類中的一個(gè)屬性返回，例如instance = Class(); err = instance.error_message
這三種方法均有利弊，需要根據(jù)項(xiàng)目的實(shí)際情況來選取，無(wú)論使用哪一種方法，都需要在整個(gè)項(xiàng)目中保持統(tǒng)一，盡可能的不要混合使用；
對(duì)于返回給前端的JSON，就需要稍微復(fù)雜一些，至少要返回2~3個(gè)字段：
code是本次調(diào)用返回的狀態(tài)碼，根據(jù)實(shí)際情況自行約定。message是狀態(tài)碼的可讀信息，用于開發(fā)人員調(diào)試或是通知用戶。data是實(shí)際返回的數(shù)據(jù)信息，很多時(shí)候可以不需要這個(gè)字段，具體的字段格式也需要根據(jù)實(shí)際情況再次進(jìn)行約定。
優(yōu)雅簡(jiǎn)單的路由保證項(xiàng)目質(zhì)量，降低維護(hù)成本。
Django有一套強(qiáng)大的路由系統(tǒng)以及路由算法，可以滿足業(yè)務(wù)中的各種需要，并且配置靈活簡(jiǎn)單，每一個(gè)路由配置文件都是URL PATH到function/class的映射。全部都可以自己設(shè)置，完全不會(huì)受到框架或是其他的一些限制。關(guān)于Django處理請(qǐng)求時(shí)的路由尋找策略可以參考文檔中的這個(gè)部分。
在配置路由中，你可以用尖括號(hào)括起來一些變量，便于在后面使用。尖括號(hào)里可以用一些"路徑轉(zhuǎn)換器（Path Converters）"來指定變量類型，例如str, int, slug, uuid, path。一個(gè)完整的URL路由文件看起來像下面這樣：
除此之外，還可以通過re_path在路由中設(shè)置正則匹配：
有些時(shí)候，你可能希望為一些URL添加一個(gè)默認(rèn)路由，例如訪問/blog/的時(shí)候返回一個(gè)默認(rèn)頁(yè)面，而訪問/blog/page
隨著項(xiàng)目的不斷擴(kuò)大，用到的路由也會(huì)不斷的變多，所以Django提供了路由包含的機(jī)制，便于我們?cè)诓煌腁pp中組織路由。我們來看一個(gè)簡(jiǎn)單的例子：
這個(gè)例子中，將所有請(qǐng)求community/*的路由全部交由aggregator.urls去解析，同理，contact/*的請(qǐng)求也全部交給了另外的路由模塊去處理；如果你的項(xiàng)目中并沒有這么多的Application，依然想通過include的方式來管理路由，那么可以采用如下方式：
一般情況下，我們的每個(gè)Django項(xiàng)目都由多個(gè)App組成，如果把所有App的路由全部放在URLCONF_ROOT里，時(shí)間久了這個(gè)文件會(huì)變的越來越難維護(hù)，十分混亂。并且，不同的App中可能會(huì)用到相同命名的路由，會(huì)產(chǎn)生沖突的情況。為了解決這些問題，我們可以通過使用"路由包含"和"命名空間"來解決，特別是如果你在維護(hù)一個(gè)可以被復(fù)用的App，為了保證路由的唯一，命名空間就顯得尤為重要了。
命名空間通常有兩種：Application namespace和Instance namespace，例如admin:index表示admin命名空間的index路由。更多關(guān)于該部分的內(nèi)容可以參考：官方文檔
Application Namespace比較好理解，指的是在應(yīng)用程序?qū)用嫔系拿臻g，一般是如下方式組織的：
Instance Namespace則指的是實(shí)例級(jí)別的命名空間，常用于一個(gè)App被多次實(shí)例化的情況，為了區(qū)分每個(gè)實(shí)例，就需要引入Instance Namespace。我們使用官方文檔中的例子看一下：
可以看到兩個(gè)路由author-polls和publisher-polls其實(shí)都包含了相同的路由，但是指定了不同的命名空間，這就是Instance級(jí)別的命名空間，即當(dāng)前正在訪問的對(duì)象的命名空間。不同的用戶身份訪問不同的URL，會(huì)得到不同的命名空間，例如游客和管理員均訪問polls:index所指向的頁(yè)面，但是由于命名空間的不同，會(huì)得到完全不同的結(jié)果。
到此，關(guān)于“Django開發(fā)方法是什么”的學(xué)習(xí)就結(jié)束了，希望能夠解決大家的疑惑。理論與實(shí)踐的搭配能更好的幫助大家學(xué)習(xí)，快去試試吧！若想繼續(xù)學(xué)習(xí)更多相關(guān)知識(shí)，請(qǐng)繼續(xù)關(guān)注創(chuàng)新互聯(lián)網(wǎng)站，小編會(huì)繼續(xù)努力為大家?guī)砀鄬?shí)用的文章！
重慶分公司
重慶分公司
