ジャンゴ
1.Django、フラスコは、トルネードのフレームワークを比較しますか？
ジャンゴ：
内部提供、ジャンゴ、大規模でよりその内部フレームアセンブリの場合：ORM、管理、ミドルウェア、フォーム、のModelForm、セッション、バッファ、信号、CSRF、すべてが完璧に機能してきました
フラスコ：
フラスコ、小型フレーム、比較的小さな内部部品、しかし,,フラスコセッションフラスコSQLAlchemyの（データベース操作）（類似のModelFormのジャンゴ、フォーム検証で）wtform、たとえば、でそれを拡張する多くのサードパーティのコンポーネントが存在します、フラスコ-移行、フラスコ・スクリプト、ウインカースケーラビリティの強力な、豊富なサードパーティ製のコンポーネント。だから、一種の短いと彼自身の簡潔な感覚があります
竜巻：
Webフレームワークは構築された軽量、非ブロック非同期+のWebSocket機能です。
「目標」：Nスレッドを介して並行処理要求（IO処理）。
内部部品：
。内部は、そのソケット達成
Bルーティングシステム。
C図。
Dテンプレート。
E.cookie
f.csrf
共通：
ジャンゴと共通でフラスコは、彼らが2つのフレームソケットを記述する必要はありませんということですので、彼らは、サードパーティのモジュールのWSGIを使用している、とトルネードソケットアセンブリを付属しています。
違い：
しかし、内部使用のWSGIは幾分異なっている：それ自体をジャンゴとwsgirefを使用して実行し、WERKZEUGのWSGIを用いてフラスコを、それらの要求管理との間の差が同じではない：Djangoはリクエストオブジェクトによる要求にパッケージし、次にパラメータを通過さ、コンテキスト管理機構を介してフラスコ一方
2. Djangoのリクエストのライフサイクル？
次にどこへ行くWSGI着信ユーザ要求、ミドルウェアをDjangoの要求、成功した経路は、対応するビュー機能と一致した後、一致するルーティング続いジャンゴ介してミドルウェア（process一メソッド）が実行され、次の機能を見ることができますデータベース操作を行うORM呼び出し、その後、テンプレートパスからテンプレートを取得します、その後、テンプレートのレンダリングが完了した後、バックグラウンドでレンダリングされたテンプレートは、文字列、ミドルウェア（方法：process_response）のすべてを、文字列になり、WSGIを返しますユーザーへ
3.一覧Djangoの組み込みコンポーネント？
フォームコンポーネント：
-検証のために、ユーザによって要求されたデータは
- HTMLタグを生成します
PS：
-フォームオブジェクトが反復可能です。
-問題：データベースから取得したデータは、データをもたらすことができる場合の選択肢は、リアルタイムで更新することはできません
-コンストラクタで値を取得するために、再度、コンストラクタメソッド、データベースを上書きします。
- ModelChoiceFieldフィールド
信号：
Djangoの信号は、実際に予約さDjangoの内部開発者のためのカスタマイズされた機能の数をフックされます。ただ、信号内の関数を登録し、その後、Djangoの内部プロセスが自動的に信号のコードの実行をトリガします。
シーン：
ログ記録の目的のために、データベーステーブル内の特定のデータを追加します。
CSRF（クロスサイトリクエストフォージェリ）：
目的：ユーザーを防止するためには、直接サーバにPOSTリクエストを開始します。
これは、XSS、で信頼できるサイトを使用するユーザの要求から迷彩を通じてサイトXSS、CSRFと信頼を使用して、ユーザーの信頼と非常に異なっています。
すべてのポスト/ジャンゴの検証のための要求1が要求本体から構成され、クライアントに文字列の生成された文字列を送信し、1が隠されたタグの内部に配置されているがprocess_viewであることを確認してください
最初は、GETリクエストを送信すると限りすることができますように繰り越すための要求を送信するとき、トークンの保存は、その後、プログラムのクッキー、フォームフォーム（隠されたinputタグ）、およびを::します。
現在、三つの主要なCSRF攻撃の防御戦略があります：1）のReferer HTTPフィールドを確認しますが、2）要求にアドレスを追加するトークンと認証; 3）HTTPヘッダとカスタムプロパティを検証..
ContentTypeを：
ContentTypeを成分（アプリ）Djangoは私たちのためにDjangoのプログラムのすべてのアプリ内のすべてのテーブルを検索し、レコードに追加されます。あなたは、達成するために、テーブルと2つのフィールドでそれを使用することができますテーブルとNテーブルがFK（フィールド）の関係を作成します。（マルチテーブルの効果との間の単純な相関関係として理解されます）
- フィールド：テーブル名
-フィールド：データIDの行を
テーブルのクーポン内部購入システム：アプリケーション。
ミドルウェア：
すべての要求のバッチ処理は、前またはビュー機能後の動作をカスタマイズすることができます。
アプリケーション：ユーザログイン認証
質問：なぜデコレータを使わないのでしょうか？
あなたがミドルウェアを使用しない場合は、各ビュー関数にデコレータを追加する必要があり、あまりにも面倒
認証コンポーネント：
その後、サインインに必要な、この時点では、認定のコンポーネントを使用する必要がある、あなたが見ることができない、ログインしていない、情報の購入アイテム：認証されたユーザーのみが、このようなとして、指定したURLアドレスにアクセスすることができます
Djangoの認証モジュールが内蔵されているユーザ認証モジュール
詳細ます。https：//www.cnblogs.com/liuqingzheng/articles/9628105.html
アクセス権コンポーネント：
セッションの許可にユーザーがログインした後、要求はすべてに来るたびに、ミドルウェアでURLと一致するように、現在のセッションによると、現在のユーザが現在のURLにアクセスしているかどうかを裁判官は、アクセス権限を持ち続けるだろう、ノーリターンはありません、ミドルウェアはセッションデータの中に入るために必要なので、process一は、当社のミドルウェアはセッションの背後に配置されているんする方法（あなたが統一された治療のためのミドルウェアを置くことができる事を確認してください）
詳細ます。https：//www.cnblogs.com/liuqingzheng/articles/9628105.html
セッション：
クッキーは、セッションを異なります
（A）クッキーは、キーと値のペアのブラウザに保存され、セッション鍵をサーバーに保存されているが、クッキーに依存しています。（クッキーに依存しないことがあり、URL、クッキー、またはより便利が、リクエストヘッダに配置することができる）
の例をログに記録する（B）を、ログインを介してクッキーは、平文のための設定キー成功し、送信クライアントへの鍵預金は、危険なリーク平文、があるかもしれません。セッションは、ユーザーに、ランダムな文字列を生成することであり、彼ら自身がサーバーを維持するでしょうが、ブラウザのクッキーを書きました。
（C）場合、ログイン認証、クッキー：ブラウザのクッキーの判断に付随する鍵送信要求、存在する場合、検証され、セッション：ユーザのクッキー要求にランダムな文字列を取得するために、ランダムな文字列に応じてセッションで確認するために、対応する値取得
キャッシュを：
内部キャッシュに一般的に使用されるデータは、ビュー機能を取ることはありません、要求はすべてprocess一経由で来て、内部のキャッシュにデータを確認し、直接、左無ビュー機能が取る
キー：1：行く前に、すべてのprocess一の実装を完了データ・キャッシュ取る
2：process_response前にキャッシュへのデータのすべての実装を完了
キャッシュ質問
：なぜキャッシュに行く前の最後のprocess一で
あるため、ユーザの要求を検証する必要のデータを返すために、仕上げ
2：キャッシュにデータが
まず、データベースからデータを受け取りビュー機能を、かかります、何のキャッシュデータが存在しない、ミドルウェアを行く
process_responseを完了したときに時間がprocess_responseに行くので、キャッシュにデータのみ、私たちの治療応答に加えてもよいです
なぜ使用のキャッシングは
頻繁に使用されると、それほど頻繁にキャッシュにデータを修正しました。
ユーザのアクセスを再度後、そこに返された場合、そこにあるかどうかを確認するためにキャッシュにアクセスしてください
。そうしないと、データベースにアクセスし、ユーザーに戻って取得（キャッシュに追加し、次の訪問するように）
前記方法は、Djangoのミドルウェア5記載しますか？Djangoのミドルウェアやアプリケーションのシナリオ？
process一（自己、要求）に一致するルーティング要求リターンを通過
（セルフ、リクエスト、コールバック、callback_args、callback_kwargs）process_viewを
リクエストメソッドを実行した後、（1）すべてのミドルウェアを「
（2）成功したマッチURL
（3）ビュー機能を取得します名前、パラメータ、（注実行されない）process_view次いで、execute（）メソッド
（4）最終的なビュー機能を実行します
目的関数の戻り値は、ビューをレンダリングしているprocess_template_response（自己、リクエスト、レスポンス）、メソッドが呼び出されます
にprocess_exception（自己、要求、例外）とすると、エラー・ビュー機能を実行し、エラーメッセージを返し
process_response（自己、リクエストを、応答）
違い6.FBVとCBV
-差はない、彼らは基本的に機能しているため。CBVの.as_view（）発送方法は、ビューの機能を返し、ビュークラスには、反射を取得/ポスト/削除/ディスパッチ処理中に入れ等によって行われ、関数を呼び出します。
：私は言葉に違い言わなければならない
CBVは、GET / POST比較的単純であり、他のビジネス機能が異なるのget /ポスト機能に入れたが- 。FBVは区別するために、独自の判断を下します。
7.Djangoは別々の読み取りを設定して作成する方法をORM？
モード：クエリセットを使用する手動の方法を使用して
第二の方法：設定ファイルを書きます
8. DjangoはあなたがCSRFトークンを運ぶために使用することができ、すべてのどの方法でベースのAjaxを使用してPOSTリクエストを送信？
一つの方法：各リクエストヘッダに連結されているAJAX
第二の方法：あなたはクッキーのトークンを取得するためには、jQueryのクッキーをダウンロードする必要が
3つの方法が：関数ajaxSetupを、前方に置くとき、この機能を実行しますAJAXリクエストの数
ログ・レコード・データが追加されたORMのテーブルを作成する方法で9.Django。
信号機能に登録：
添加することができる信号機構ジャンゴを使用して、データをドロップした後にログを提供
＃Djangoはコンストラクタを実行する際に、自動的にトリガpre_initオブジェクト・モデルの前に
その構築方法の実行中にモデルオブジェクトpost_init位ジャンゴを、自動的にトリガ
にpre_save＃Djangoに自動的にトリガする保存された旧モデルオブジェクト
オブジェクトpost_save＃ジャンゴのモデルは、保存は、自動的にトリガ
削除を自動的にトリガにpre_delete＃Djangoのモデルオブジェクトの前に
自動的に削除トリガーにpost_delete＃Djangoのモデルオブジェクトの後に
RESTfulな仕様のご理解約10での話？
RESTfulな実際に書き込まれた「合意」のインターフェイスのセットが書く方法と、戻り値、ステータスコードを設定する方法を指定します。
＃最も注目すべき機能：
安らかで＃：
ユーザーにURLを与え、方法に応じて異なる処理を異なるバックエンド
例：ポストは、データを作成し、データ収集を取得し、パッチを入れて、データを変更、削除データを削除します。
＃安らかないでください：
ADD_USER / delte_user / EDIT_USER /：URLの多くは、それぞれのような機能、表すURL呼び出し元に
当然の＃、などなど、他のプロトコルがあります：
共存の複数のバージョンが存在するような状況を制御するために、「バージョン」プログラムをバージョンを配置することができるURL、要求ヘッダー
（/カスタムを受け入れる）、GETパラメータ
「ステータスコード」200/300/400/500
200 OKです- [GET]：サーバが正常にユーザによって要求されたデータを返し、操作が冪等であります（べき等）。
400 INVALID REQUEST - [POST / PUT / PATCH]： ユーザー誤って発行された要求、サーバは操作データを作成または変更しない、操作が冪等です。
404が見つかりません- [*]：ユーザーがサーバーが操作されていない、記録の要求が存在しない発行し、操作が冪等です。
500内部サーバーエラー- [*] ：サーバーエラーが発生し、利用者は、要求が正常に送信されたかどうかを確認することができません。
安らかなとも呼ばれる「リソース指向プログラミング『「という用語の使用を作るためのURL」
』と記されたAPI "
api.sex.com APIは、（クロスドメインの問題があるでしょう）専用のドメイン名を展開しようとします
www.sex.com/api/
11. RPCとは何ですか？
「リモートプロシージャコールプロトコルは、」基本的なネットワークプロトコル技術を理解していなくても、ネットワークを介してリモートコンピュータからのサービスの要求です。
進化の順序：従来のRPC、その後、いくつかのRESTfulな仕様
12.なぜDjangoの残りのフレームワークフレームワークを使うのか？
内部には、我々が配置することにより、対応する操作を完了することができ、私たちの便利なコンポーネントの多くを助けた
「シリアライズ」ユーザデータ確認要求クエリセット+ JSONと呼ばれるシリアライズされたオブジェクト、「パーサ」かもしれユーザの要求を取得します：など、ためにデータrequest.dataは、自動的にデータのヘッダは、ページ表示で取得したデータのデータベース・ページからコンテンツ・タイプ、「タブ」に従って解析することができない要求します。
他のコンポーネントがあります：「認証」、「権威」、「アクセス頻度制御
フラスコ
1.Flaskの利点？
多くのサードパーティのライブラリの、自由な柔軟でスケーラブルな、透明かつ制御可能な選択肢をフラスコ、最も人気のある強力なPythonライブラリの開発時間と組み合わせることができます。
何に依存2.Flask Frameworkコンポーネント？
依存Jinja2のテンプレートエンジンは
werkzurg合意に依存しています
3.Flaskアクション青写真
モジュールのさまざまな機能を分離するための青写真もそれぞれ異なる機能を実現するに大きなアプリケーションモジュールである。
青写真青写真でビューの別の関数を呼び出すことができ、適当な青写真を追加します名前。
？フラスココンテキスト管理プロセス4 DESCRIPTION
：＃aは、単に、falskコンテキスト管理は、3つのフェーズに分けることができる
1 '要求が来た『に配置されたコンテキスト管理に関するデータ要求
機能を考慮して2』で「：行くコンテキスト管理の値が
3」要求応答を「：コンテキスト管理にデータを消去するには
＃bの、精巧である：
1、」単に「来たリクエスト：
リクエスト、パッケージRequestContextの中にセッションクラスアプリは、G AppContextをRequestContextのローカルクラスにクラスにカプセル化され、そしてLocalStack AppContextをすることにより
2、 'ビュー関数'：
localproxyによって--->一部の機能---> localstack --->ローカル値
3 、「要求に応じて」：
ローカルクリアランス内の最初の実行save.session（）をそれぞれ実行POP（）、データ
でG 5.Flaskの役割？
要求が来るとCURRENT_APP G AppContextをクラスとしてパッケージするとき、グローバル変数を通してGは、その後、ローカルにLocalStack AppContextを、LocalStackの値、部分関数値によってローカル時刻によって、要求である応答ローカルデータ削除中のG：
6.Flask実行プロセス？
7.一部の機能は何ですか？
簡単に言えばfunctools.partial役割は（つまり、デフォルト値を設定されている）、新しい関数を返すの固定の機能にいくつかのパラメータを置くことで、容易になります。この新しい関数を呼び出します
例えば：
#假设对int(x, base = 10)，进行二次封装
#通常做法
def to_int2(x):
return int(x, base = 2)
print(to_int2(‘101‘))
#偏函数 做法
import functools
to_int2_partial = functools.partial(int, base = 2)
print(to_int2_partial(‘101‘,base=2))
#partial的函数声明
#def __init__(self, func, *args, **keywords):
#由此处可以看到其实就是做了
#int(**keywords) ==>kw = {‘base‘ = 2} 然而‘101’会以*args的形式传入到函数
print(to_int2_partial(‘101‘,base=10))
#result --> 101
小扁は、あなたは大きなまたは小さな白い牛であるか、一緒になって進捗状況を理解することを学ぶために一緒に来ることができるラインに切り替えたいかどうか、研究グループ315346913 Pythonの学習をお勧めします！ツールは、呉服や技術情報共有の多くは、グループ内にあります。