關於 Django 資料驅動 Web 應用的總體設計
把資料存取邏輯、業務邏輯和表現邏輯組合在一起的概念有時被稱為軟體架構的 Model-View-Controller (MVC)模式。在這個模式中， Model 代表資料存取層，View 代表的是系統中選擇顯示什麼和怎麼顯示的部分，Controller 指的是系統中根據使用者輸入並視需要訪問模型，以決定使用哪個檢視的那部分。

為什麼用縮寫？

像 MVC 這樣的明確定義模式的主要用於改善開發人員之間的溝通。比起告訴同事，“讓我們採用抽象的資料存取方式，然後單獨劃分一層來顯示資料，並且在中間加上一個控制它的層”，一個通用的說法會讓你收益，你只需要說：“我們在這裡使用MVC模式吧。

Django 緊緊地遵循這種 MVC 模式，可以稱得上是一種 MVC 框架。以下是 Django 中 M、V 和 C 各自的含義：

M ，資料存取部分，由django資料庫層處理，

V ，選擇顯示哪些資料要顯示以及怎樣顯示的部分，由檢視和模板處理。

C ，根據使用者輸入委派檢視的部分，由 Django 框架根據 URLconf 設定，對給定 URL 呼叫適當的 Python 函式。

由於 C 由框架自行處理，而 Django 裡更關注的是模型（Model）、模板(Template)和檢視（Views），Django 也被稱為 MTV 框架。在 MTV 開發模式中：

M 代表模型（Model），即資料存取層。該層處理與資料相關的所有事務：如何存取、如何驗證有效性、包含哪些行為以及資料之間的關係等。

T 代表模板(Template)，即表現層。該層處理與表現相關的決定：如何在頁面或其他型別文件中進行顯示。

V 代表檢視（View），即業務邏輯層。該層包含存取模型及調取恰當模板的相關邏輯。你可以把它看作模型與模板之間的橋樑。

在這裡插入圖片描述
各種元件都是鬆耦合的，每個由 Django驅動的Web應用都有著明確的目的，並且可獨立更改而不影響到其它的部分。

Django是怎麼處理請求的？–url
在我們的檢視功能之前，讓我們暫停一下去了解更多一些有關Django是怎麼工作的知識. 具體地說，當你通過在瀏覽器裡敲http://127.0.0.1:8000/hello/來訪問Hello world訊息得時候，Django在後臺有些什麼動作呢？

所有均開始於setting檔案。當你執行python manage.py runserver，指令碼將在於manage.py同一個目錄下查詢名為setting.py的檔案。這個檔案包含了所有有關這個Django專案的配置資訊，均大寫： TEMPLATE_DIRS , DATABASE_NAME , 等. 最重要的設定：ROOT_URLCONF，它將作為URLconf告訴Django在這個站點中那些Python的模組將被用到

還記得什麼時候django-admin.py startproject建立檔案settings.py和urls.py嗎？自動建立的settings.py包含一個ROOT_URLCONF配置用來指向自動產生的urls.py. 開啟檔案settings.py你將看到如下：

ROOT_URLCONF = ‘mysite.urls’
相對應的檔案是mysite/urls.py

當訪問 URL /hello/ 時，Django 根據 ROOT_URLCONF 的設定裝載 URLconf 。然後按順序逐個匹配URLconf裡的URLpatterns，直到找到一個匹配的。當找到這個匹配的URLpatterns就呼叫相關聯的view函式，並把 HttpRequest 物件作為第一個引數。（稍後再給出 HttpRequest 的更多資訊）（我們將在後面看到HttpRequest的標準）

正如我們在第一個檢視例子裡面看到的，一個檢視功能必須返回一個HttpResponse。一旦做完，Django將完成剩餘的轉換Python的物件到一個合適的帶有HTTP頭和body的Web Response，（例如，網頁內容）。

總結一下：
進來的請求轉入/hello/.

Django通過在ROOT_URLCONF配置來決定根URLconf.

Django在URLconf中的所有URL模式中，查詢第一個匹配/hello/的條目。

如果找到匹配，將呼叫相應的檢視函式

檢視函式返回一個HttpResponse

Django轉換HttpResponse為一個適合的HTTP response，以Web page顯示出來

V—檢視：
在使用django-admin startproject ** 建立完專案並使用manage.py建立apps後，

建立一個叫做views.py的空檔案。這個Python模組將包含這一章的檢視。請留意，Django對於view.py的檔案命名沒有特別的要求，它不在乎這個檔案叫什麼。但是根據約定，把它命名成view.py是個好主意，這樣有利於其他開發者讀懂你的程式碼

每個檢視函式至少要有一個引數，通常被叫作request。這是一個觸發這個檢視、包含當前Web請求資訊的物件，是類django.http.HttpRequest的一個例項。

因為我們的專案還對新建的檢視一無所知。我們需要通過一個詳細描述的URL來顯式的告訴它並且啟用這個檢視。（繼續我們剛才類似釋出靜態HTML檔案的例子。現在我們已經建立了HTML檔案，但還沒有把它上傳至伺服器的目錄。）為了繫結檢視函式和URL，我們使用URLconf。

URLconf 就像是 Django 所支撐網站的目錄。它的本質是 URL 模式以及要為該 URL 模式呼叫的檢視函式之間的對映表。你就是以這種方式告訴 Django，對於這個 URL 呼叫這段程式碼，對於那個 URL 呼叫那段程式碼。例如，當用戶訪問/foo/時，呼叫檢視函式foo_view()，這個檢視函式存在於Python模組檔案view.py中。

當前應該注意是 urlpatterns 變數， Django 期望能從 ROOT_URLCONF 模組中找到它。該變數定義了 URL 以及用於處理這些 URL 的程式碼之間的對映關係。預設情況下，URLconf 所有內容都被註釋起來了——Django 應用程式還是白版一塊。

我們為urlpatterns加上一行： (‘^hello/$’, hello), 這行被稱作URLpattern，它是一個Python的元組。元組中第一個元素是模式匹配字串（正則表示式）；第二個元素是那個模式將使用的檢視函式。
簡單來說，我們只是告訴 Django，所有指向 URL /hello/ 的請求都應由 hello 這個檢視函式來處理。

Django在檢查URL模式前，移除每一個申請的URL開頭的斜槓(/)。這意味著我們為/hello/寫URL模式不用包含斜槓(/)。（剛開始，這樣可能看起來不直觀，但這樣的要求簡化了許多工作。

M–模型
DATABASE_ENGINE 告訴Django使用哪個資料庫引擎。如果你在 Django 中使用資料庫， DATABASE_ENGINE 必須是 Django中指定出的值
第一步是用Python程式碼來描述它們。開啟由startapp 命令建立的models.py 並輸入下面的內容：1

from django.db import models

class Publisher(models.Model):
name = models.CharField(max_length=30)
address = models.CharField(max_length=50)
city = models.CharField(max_length=60)
state_province = models.CharField(max_length=30)
country = models.CharField(max_length=50)
website = models.URLField()

class Author(models.Model):
first_name = models.CharField(max_length=30)
last_name = models.CharField(max_length=40)
email = models.EmailField()

class Book(models.Model):
title = models.CharField(max_length=100)
authors = models.ManyToManyField(Author)
publisher = models.ForeignKey(Publisher)
publication_date = models.DateField()
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
“每個資料庫表對應一個類”這條規則的例外情況是多對多關係。在我們的範例模型中， Book 有一個多對多欄位叫做 authors 。該欄位表明一本書籍有一個或多個作者，但 Book 資料庫表卻並沒有 authors 欄位。相反，Django建立了一個額外的表（多對多連線表）來處理書籍和作者之間的對映關係。

最後需要注意的是，我們並沒有顯式地為這些模型定義任何主鍵。除非你單獨指明，否則Django會自動為每個模型生成一個自增長的整數主鍵欄位每個Django模型都要求有單獨的主鍵。id

完成這些程式碼之後，現在讓我們來在資料庫中建立這些表。要完成該項工作，第一步是在 Django 專案中啟用這些模型。將 books app 新增到配置檔案的已安裝應用列表中即可完成此步驟。再次編輯 settings.py 檔案，找到 INSTALLED_APPS 設定。INSTALLED_APPS 告訴 Django 專案哪些 app 處於啟用狀態。

現在我們可以建立資料庫表了。首先，用下面的命令驗證模型的有效性：

python manage.py check
check命令檢查你的模型的語法和邏輯是否正確。如果一切正常，你會看到 0 errors found 訊息。如果出錯，請檢查你輸入的模型程式碼。錯誤輸出會給出非常有用的錯誤資訊來幫助你修正你的模型。

模型確認沒問題了，執行下面的命令來生成 CREATE TABLE 語句
python manage.py makemigration books
命令並沒有在資料庫中真正建立資料表，只是把SQL語句段打印出來，這樣你可以看到Django究竟會做些什麼

python manage.py migrate
命令是同步你的模型到資料庫的一個簡單方法。它會根據 INSTALLED_APPS 裡設定的app來檢查資料庫，如果表不存在，它就會建立它。

一旦你建立了模型，Django自動為這些模型提供了高階的Python API

from books.models import Publisher
p1 = Publisher(name='Apress', address='2855 Telegraph Avenue',
... city='Berkeley', state_province='CA', country='U.S.A.',
... website='http://www.apress.com/')

p1.save()
p2 = Publisher(name="O'Reilly", address='10 Fawcett St.',
... city='Cambridge', state_province='MA', country='U.S.A.',
... website='http://www.oreilly.com/')
當你使用Django modle API建立物件時Django並未將物件儲存至資料庫內，除非你呼叫 save() 方法：

p2.save()
如果需要一步完成物件的建立與儲存至資料庫，就使用 objects.create() 方法。下面的例子與之前的例子等價：
p2 = Publisher.objects.create(name="O'Reilly",
... address='10 Fawcett St.', city='Cambridge',
... state_province='MA', country='U.S.A.',
... website='http://www.oreilly.com/')

publisher_list = Publisher.objects.all()
publisher_list
[<Publisher: Publisher object>, <Publisher: Publisher object>]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
當然，建立新的資料庫，並更新之中的資料是必要的，但是，對於 Web 應用程式來說，更多的時候是在檢索查詢資料庫。我們已經知道如何從一個給定的模型中取出所有記錄：

Publisher.objects.all()
[<Publisher: Apress>, <Publisher: O’Reilly>]
這相當於這個SQL語句：

SELECT id, name, address, city, state_province, country, website
FROM books_publisher;
注意到Django在選擇所有資料時並沒有使用 SELECT* ，而是顯式列出了所有欄位。設計的時候就是這樣： SELECT* 會更慢，而且最重要的是列出所有欄位遵循了Python 界的一個信條：明言勝於暗示。

我們很少會一次性從資料庫中取出所有的資料；通常都只針對一部分資料進行操作。在Django API中，我們可以使用filter() 方法對資料進行過濾：

Publisher.objects.filter(name=‘Apress’)
[<Publisher: Apress>]

上面的例子中filter() 函式返回一個記錄集，這個記錄集是一個列表。相對列表來說，有些時候我們更需要獲取單個的物件， get() 方法就是在此時使用的：

Publisher.objects.get(name=“Apress”)
<Publisher: Apress>
這樣，就返回了單個物件，而不是列表（更準確的說，QuerySet)。所以，如果結果是多個物件，會導致丟擲異常

在執行前面的例子中，你可能已經注意到返回的結果是無序的。我們還沒有告訴資料庫怎樣對結果進行排序，所以我們返回的結果是無序的。在你的 Django 應用中，你或許希望根據某欄位的值對檢索結果排序，比如說，按字母順序。那麼，使用 order_by() 這個方法就可以搞定了

Publisher.objects.filter(country=“U.S.A.”).order_by("-name")
[<Publisher: O’Reilly>, <Publisher: Apress>]
你應該沒猜錯，轉換成SQL查詢就是 WHERE 和 ORDER BY 的組合：

在“插入和更新資料”中，我們有提到模型的save()方法，這個方法會更新一行裡的所有列。而某些情況下，我們只需要更新行裡的某幾列
在這個例子裡我們可以看到Django的save()方法更新了不僅僅是name列的值，還有更新了所有的列。若name以外的列有可能會被其他的程序所改動的情況下，只更改name列顯然是更加明智的。更改某一指定的列，我們可以呼叫結果集（QuerySet）物件的update()方法：示例如下：

Publisher.objects.filter(id=52).update(name=‘Apress Publishing’)
update()方法對於任何結果集（QuerySet）均有效，這意味著你可以同時更新多條記錄。

T–模板
建立一個Template 物件最簡單的方法就是直接例項化它。Template 類就在 django.template 模組中，建構函式接受一個引數
一旦你建立一個 Template 物件，你可以用 context 來傳遞資料給它。一個context是一系列變數和它們值的集合。

context在Django裡表現為 Context 類，在 django.template 模組裡。她的建構函式帶有一個可選的引數：一個字典對映變數和它們的值。呼叫 Template 物件的 render() 方法並傳遞context來填充模板

def search_book(request):
return render(request,template_name='search_form.html')

def current_datetime(request):
now = datetime.datetime.now()
t = Template("It is now {{ current_date }}.")
html = t.render(Context({'current_date': now}))
return HttpResponse(html)
1
2
3
4
5
6
7
8
模板系統能夠非常簡潔地處理更加複雜的資料結構，例如list、dictionary和自定義的物件。

在 Django 模板中遍歷複雜資料結構的關鍵是句點字元 (.)。

同樣，也可以通過句點來訪問物件的屬性。比方說， Python 的 datetime.date 物件有 year 、 month 和 day 幾個屬性，你同樣可以在模板中使用句點來訪問這些屬性：

from django.template import Template, Context
import datetime
d = datetime.date(1993, 5, 2)
d.year
1993

d.month
5

d.day
2

t = Template(‘The month is {{ date.month }} and the year is {{ date.year }}.’)
c = Context({‘date’: d})
t.render©
u’The month is 5 and the year is 1993.’

為了減少模板載入呼叫過程及模板本身的冗餘程式碼，Django 提供了一種使用方便且功能強大的 API ，用於從磁碟中載入模板，
要使用此模板載入API，首先你必須將模板的儲存位置告訴框架。設定的儲存檔案就是我們前一章節講述ROOT_URLCONF配置的時候提到的 settings.py。

開啟你的settings.py配置檔案，找到TEMPLATE_DIRS這項設定吧。它的預設設定是一個空元組（tuple），加上一些自動生成的註釋。

TEMPLATE_DIRS = (

Put strings here, like “/home/html/django_templates” or “C:/www/django/templates”.

Always use forward slashes, even on Windows.

Don’t forget to use absolute paths, not relative paths.

)
該設定告訴 Django 的模板載入機制在哪裡查詢模板。選擇一個目錄用於存放模板並將其新增到 TEMPLATE_DIRS 中：

TEMPLATE_DIRS = (
‘/home/django/mysite/templates’,
)
最省事的方式是使用絕對路徑（即從檔案系統根目錄開始的目錄路徑）。如果想要更靈活一點並減少一些負面干擾，可利用 Django 配置檔案就是 Python 程式碼這一點來動態構建 TEMPLATE_DIRS 的內容，如：例如：

import os.path

TEMPLATE_DIRS = (
os.path.join(os.path.dirname(file), ‘templates’).replace(’\’,’/’),
)

這個模板語言來源於World Online的開發經驗和Django創造者們集體智慧的結晶。下面是關於它的一些設計哲學理念：

業務邏輯應該和表現邏輯相對分開。我們將模板系統視為控制表現及表現相關邏輯的工具，僅此而已。模板系統不應提供超出此基本目標的功能。
出於這個原因，在 Django 模板中是不可能直接呼叫 Python 程式碼的。所有的程式設計工作基本上都被侷限於模板標籤的能力範圍。當然，是有可能寫出自定義的模板標籤來完成任意工作，但這些“超範圍”的 Django 模板標籤有意地不允許執行任何 Python 程式碼。1

語法不應受到 HTML/XML 的束縛。儘管 Django 模板系統主要用於生成 HTML，它還是被有意地設計為可生成非 HTML 格式，如純文字。一些其它的模板語言是基於 XML 的，將所有的模板邏輯置於 XML 標籤與屬性之中，而 Django 有意地避開了這種限制。強制要求使用有效 XML 編寫模板將會引發大量的人為錯誤和難以理解的錯誤資訊，而且使用 XML 引擎解析模板也會導致令人無法容忍的模板處理開銷。

假定設計師精通 HTML 編碼。模板系統的設計意圖並不是為了讓模板一定能夠很好地顯示在 Dreamweaver 這樣的所見即所得編輯器中。這種限制過於苛刻，而且會使得語法不能像目前這樣的完美。 Django 要求模板創作人員對直接編輯 HTML 非常熟悉。2

[Django]MVT模式的詳解

Put strings here, like “/home/html/django_templates” or “C:/www/django/templates”.

Always use forward slashes, even on Windows.

Don’t forget to use absolute paths, not relative paths.

[Django]MVT模式的詳解

基於ROS 服務通訊模式詳解

VPS CENTOS 上配置python,mysql,nginx,uwsgi,django的方法詳解

關於pytorch中全連線神經網路搭建兩種模式詳解

python re模組匹配貪婪和非貪婪模式詳解

《javascript設計模式》學習筆記七：Javascript面向物件程式設計組合模式詳解

JavaScript設計模式之觀察者模式與釋出訂閱模式詳解

JavaScript設計模式---單例模式詳解【四種基本形式】

socket緩衝區以及阻塞模式詳解

設計模式之單例模式詳解

Java設計模式之23種設計模式詳解

單例模式詳解

Django Models Choices 詳解

Redis詳解（九）- 哨兵(Sentinel)模式詳解

設計模式詳解及Python實現

Javascript設計模式系統講解與應用，JS設計模式詳解

Linux系統CentOS進入單使用者模式和救援模式詳解

JAVA設計模式簡介及六種常見設計模式詳解

PHP 執行模式詳解

Sphinx匹配模式詳解[轉]

[Django]MVT模式的詳解

Put strings here, like “/home/html/django_templates” or “C:/www/django/templates”.

Always use forward slashes, even on Windows.

Don’t forget to use absolute paths, not relative paths.

相關推薦