まず、テーブルのリレーションシップを作成します

例えば本の形、プレステーブル、詳細テーブルのテーブルや著者、で

1対多

ブックpublishersテーブルとテーブルは一対多の関係であります

2.多

本と著者のテーブルは、多くの関係しています

3.マンツーマン

テーブルとauthorテーブルの詳細については、1対1の関係であります

実装

クラスブック（models.Model）：
    ＃は、上記のIDが自動的に私たちが書いていないことを作成された 
    タイトル= models.CharField（64 MAX_LENGTH = ）
     ＃。価格小数フィールド2進の会計処理8の合計 
    価格= models.DecimalField（max_digitsを。8 =、decimal_places = 2 ）

    ＃本と出版社は、多くの外部キー関係がある 
    （=へ= models.ForeignKeyを公開「公開」）   ＃のデフォルトのフィールドである関連するプレステーブルの主キーフィールド
    ＃は＃に、後にも（=公開すること）= models.ForeignKey公開あなたは、変数名が現在の位置の上に表示されることを保証するために、変数名のテーブルが、必要に直接書き込むことができます

    ＃本と著者多くの外部キーの関係に多くのある 
    作家で= models.ManyToManyField（=に「著者」）   ＃の書籍や著者は、多くの関係です
    。「」 "
    著者フィールドは、実際に表に出て作成していない仮想フィールドであります
    唯一のジャンゴORMブックを伝えるために使用されると、著者は、第三のテーブルを作成する必要があります
    「」」

テーブルブック

クラス公開（models.Model）：
    名前 = models.CharField（max_lengthを= 64 ）
    ADDR = models.CharField（MAX_LENGTH = 64）

テーブルを公開

クラスの著者（models.Model）：
    名前 = models.CharField（MAX_LENGTH = 32 ）
    電話 = models.BigIntegerField（）
    ＃1の外部キー関係の構築 
    （=にauthor_detail = models.OneToOneFieldを' AuthorDetail '）

authorテーブル

クラスAuthorDetail（models.Model）：
    年齢 = models.IntegerField（）
    ADDR = models.CharField（MAX_LENGTH = 255）

authorDetail表

注：表を書いている時点で、その後、すべての書き込みの後に最初のベーステーブルへの外部キーフィールドとの関係を考えます

　　 Djangoは、書籍、多くの関係は、リレーショナル表を行くと、私たちはテーブルのテーブルを作成するのに役立ち、テーブル内のフィールドと我々は通常、コンテンツを作成するのと同じです

　　作成したテーブルが自動的に接尾辞に追加されているORMのForeignKeyフィールドとOneToOneFieldフィールドには、接尾辞_id、我々が必要としないので、フィールドを_idプラス

二、ジャンゴフローチャートリクエストのライフサイクル

第三に、ルーティング層

1.ルート試合

次のコードurls.pyで

urlpatterns = [
    URL（R ' ^管理/ ' 、admin.site.urls）、
]

方法のURLパラメータが正規表現、正規のルートはすぐに機能を表示するために、対応する正規の実行内容に適合させることができる後でマッチマッチングされるパラメータは、好ましくは、開始シンボルと結合されているので、マッチは、続行されません：「^ 「と終了文字：」$ '

最後のスラッシュのないユーザー入力URL、Djangoが自動的にコンフィギュレーションファイル内の関数を開くかどうかを指定することができ、デフォルトを追加します。APPEND_SLASH =真/偽

2.グループ

グループ化は、括弧内のいくつかの正規表現を与えることです

不明グループ

正規表現の括弧に一致する場合、対応するビュー・パラメータが関数に渡されるコンテンツの位置に一致します

　　構文をルーティング：

　　URL（R '^テスト/（[0-9] {4}）/'、views.test）

　　ビュー機能：後方位置にパラメータを追加する必要があります

　　デフ指数（リクエスト、引数）

有名なグループ化

ブラケットは、ビュー関数に渡されたパラメータに対応するコンテンツ鍵などの正規表現と一致する場合、正規表現エイリアスからの期間、一致します

　　構文をルーティング：

　　URL（R '^テスト/（？P <年> \ D +）/'、views.test）

　　ビュー機能：

　　デフ指数（リクエスト、年）

追加：不明な有名な缶が混合されていません

　　　ミックスが、あなたはより多くの同じネーミングを使用することができませんが、

逆引き参照

いくつかの手段で、対応するURLにアクセスすることができ、結果を得ることが可能です

どのように使用するには：

　　（r 'を^ testadd /'、views.testadd、名前= '追加'）URLを： - ビュー機能ルーティングと名の対応関係を与えます

　　- 遠位分析：{％のURL '追加' ％}

　　- バックエンド解析：django.shortcutsから逆輸入

　　　　　　　逆（「追加」）

- 無名のグループ化の逆引き

　　ルーティング構文：URL（R '^ testadd /（\ dは+）/'、views.testadd、名前= '追加'）

　　遠位分析：{％URL '追加' 1％}

　　後分析：逆（ '追加'、引数=（12））

- 有名なグループ化の逆引き

　　ルーティング構文：URL（R、Views.testadd、名前は= '追加' '^ testadd /（P <年> \ D +）/？'）

　　遠位分析：推奨＃{％のURL 1％ 'を追加'}

　　後分析：逆（ '追加'、引数=（12））

「」」
    擬似コード：
    URL（R '^ EDIT_USER /（\ dは+）/'、views.edit_user、名前= '編集'）
        
        
    {user_queryset％でUSER_OBJ用％}
        <a href="edit_user/{{ user_obj.id }}/">编辑する</a>
        <a href="{% URL'edit' user_obj.id %}">编辑する</a>
    {％ENDFOR％}
        
        
    デフEDIT_USER（リクエスト、edit_id）：
        （ '編集' を、引数=（edit_id、））リバース
    
「」」

3.ルート分布

多くの関係の観点から機能対応するルーティングするときのDjangoプロジェクトが比較的大きい場合、総ルーティング・コードが長すぎます。口座に合計ルーティングコードを撮影することは、悪いメンテナンス、各アプリは、独自のurls.pyを持つことはできませんし、合計ルートがもはや分布の唯一のタスクをルーティングし、ビューの機能との対応を行いますが、1つの操作のみジャンゴサポートです。

要求に応じて、現在の要求を特定する機能へのアクセスを必要とするアプリケーションが自動的に対応するアプリurls.pyの内部に送達し、次いでurls.py内部アプリビュー機能と一致するルートを行う属し

合計ルート：

django.conf.urlsはインポート含めます

URL（R ' ^ app01 / '、（含ま' app01.urls ' ））を、
URL（R ' ^ app02 / 'が含まれる（' app02.urls '））

サブルーティング：

＃app01 
から django.conf.urlsのインポートURL
 から app01 インポートビュー

urlpatterns = [
URL（R ' ^インデックス/ ' 、views.index）
]
    

＃app02     
から django.conf.urlsのインポートURL
 から app02 インポートビュー

urlpatterns = [
URL（R ' ^インデックス/ ' 、views.index）
]

第四に、名前空間

各アプリは、独自のurls.py追加を持つことができ、それはまた、テンプレートフォルダ独自の静的テンプレートファイルを持つことができ、小グループでの上記の特徴に基づいてジャンゴベースの開発に、余分なシンプルになりますが、同時に異なるがあるでしょうAPPは、同じビュー機能の別名で表示され、競合を作成します。

ソリューション：

1.名前空間の使用

URL（R ' ^ app01 / '、（含ま' app01.urls '、名前空間= ' app01 ' ））
URL（R ' ^ app02 / '、（含ま' app02.urls '、名前空間= ' app02 ' ））


バックエンドの分析
逆（' app01：インデックス' ）
逆（' app02：インデックス' ）
フロントエンドの分析
{％URL ' app01：インデックス'％}
{％URL ' app02：インデックス'％}

2.アプリケーション名を別名プレフィックスから、現在のアプリケーションと組み合わせると

URL（R ' ^インデックス/ '、views.index、名前= ' app01_index ' ）
URL（R ' ^インデックス/ '、views.index、名前= ' app02_index '

第五に、仮想環境

さまざまなプロジェクトのために何をしたい、プロジェクトに必要な機能ブロックのみをインストールし、プロジェクト未満でないと仮想環境を使用する必要性、ロード時の資源浪費を避けるために、着用しないだろう

Djangoのバージョンの違い：

層のルーティング：

　　URLを使用1.X

　　パスを使用し2.X

パスの最初の引数は何でも、re_pathと同じURLに書くためにどのような一致、正規表現をサポートしていませんが、正規表現は、最初の引数をURL

パスは正規表現をサポートしていませんが、それは5デフォルトのコンバータを提供していますが。

　　-デフォルトの形態であるマッチングパスセパレータ（/）の外側に加えて、非空の文字列str、
　　INT、0を含む正の整数を、マッチ- 。
　　-スラッグ文字列、文字、数字、バー、アンダースコアに一致します。
　　- UUID、マッチング075194d3-6885-417e-a8a8-6c931e272f00として、UUIDフォーマット。
　　-パスは、パスの区切り文字（/）を含む、任意の非空の文字列に一致する（しませんか？）

　　構文：パス（ 'ログイン/ <INT：年> /'、ログイン）

デフォルトに加えて、5 Converterはまた、コンバータをカスタマイズすることをサポートします

クラスMonthConverter：
正規表現 = ' \ D {2} '  ＃のプロパティ名必須正規表現

デフto_python（自己、値）：
     戻りint型（値）

DEF to_url（自己、値）：
     返り値＃1 マッチ正規表現は、2つの番号であり、返された結果は、2つの数値でなければなりません

補足：

1.擬似静的：

.htmlをで終わるURLは、紙が死んで書かれていたかのような印象を与えやすいの内容変更されません
役割を：あなたのウェブサイトの検索エンジンを向上させるために、効率的なクエリのSEOのウェブサイトを提供するために、コレクションの努力であります

2.ビュー層：

ビュー機能は、のHttpResponseを返す必要があります

3.JsonResponse：

django.http 輸入JsonResponse
 デフXXX（リクエスト）：
user_dict = { ' ユーザ名'：' タンクタンク'、' パスワード'：' 123 ' }
 ＃json_str = json.dumps（user_dict、ensure_ascii =偽）
＃のリターンのHttpResponse（json_str） 
＃ときシーケンスjsonResponseオブジェクトは、二つのステップ上にカプセル化json_dumps_params =中国語の目的は、必要辞書追加する場合{ 'ensure_asciiを'偽} 
戻り jsonResponse（user_dict、json_dumps_params = { ' ensure_ascii ' ：FALSE}）

L = [1,2,3,4,5,6,7,8,9 、】
 戻り jsonResponse（L、安全=偽）   ＃Falseに必要な非辞書安全な直列化形式のデータを

ジャンゴ（C）