Django開発手法とは

パート 1. 始める前に

Django は、強力な Web アプリケーション フレームワークとして、近年徐々に人気が高まっています。Django を採用する Python 開発者がますます増えています。 Django には多くのコンテンツがあるため、誰もが初めて Django に入るときは、常に「少し圧倒されている」ように感じ、どこから始めればよいのかわかりません。または、最初に理解した後でも、現在のアプローチが洗練されているかどうか、プロジェクトをどのように編成するか、コードをより再利用しやすくする方法がまだわかりません。

パート 2. プロジェクト構造

優れたプロジェクト構造は、戦いの半分を達成したものです。

2.1 全体的な構造

デフォルトでは、Django によって生成されるプロジェクト構造はおおよそ次のようになります。

With As theプロジェクト内のアプリケーションの数が増加し続けると、ローカル ルート ディレクトリ内のパッケージの数も増加し続け、保守がますます困難になるため、プロジェクト全体について明確な計画を立て、各ファイルを合理的に配置する必要があります。

プロジェクトが小さく、プロジェクト内のアプリケーションを再利用する予定がない場合は、次の方法を検討できます:

venv フォルダープロジェクトが保存される virtualenv 環境はオプションであり、他の場所に配置できます。

データベース このアプリは、モデルの保存、テンプレートで使用されるコマンドといくつかのカスタム フィルターの管理に特に使用され、プロジェクトのルート ディレクトリに保存されます。

docs と logs には、実行時に生成されるプロジェクト関連のドキュメントとログ ファイルがそれぞれ保存されます。

static は、css/js/img/font などの静的ファイルを保存します。

utils には、ツール関数、プロジェクトで使用されるクラス、およびロガーなどのいくつかの共通モジュールが保存されます。

templates には、テンプレート ファイルが格納されます。親テンプレート、または複数のテンプレートによって継承されたテンプレートは、ルート ディレクトリに配置され、メンテナンスを容易にするために、base などの名前が付けられます。残りのテンプレートは、対応するアプリケーション名のフォルダーに配置されます。 。

Web ディレクトリにはすべてのアプリケーションが保存されます。アプリケーションが多数ある場合は、計画のためにさらに多くのパッケージに分割できます。各パッケージにはアプリケーションの種類が保存されます。

2.2 モデル

モデル モジュール部分では、主にデータのクラスへのマッピングに関係します。通常の状況では、各テーブルに対応するクラスは別のファイルを用意し、models/__init__.py にある対応するクラスを順番にインポートして、他の場所で使用するときに、fromdatabase.models import xxxx からインポートできるようにします。クラスに名前を付けるときは、次の名前を追加することをお勧めします。たとえば、ここに Cherry という名前のプロジェクトがあり、その場合、すべてのクラスは CherryLeaks、CherryVulns などになります。

モデルに別のマネージャーを追加し、操作の繰り返しを避けるために対応するメソッドを実装することをお勧めします。

さらに、実際の状況に応じて選択できるいくつかの提案があります:

外部キーなどの型の使用は推奨されません

各テーブル、created_time、updated_time フィールドに is_deleted を追加します。

インデックスを上手に活用します

2.3 View

ほとんどのビジネス ロジックは View 部分に配置する必要があります。この部分が核心となるはずです。ここでは、同様の機能を持つすべてのビューを同じファイルに配置することもお勧めします。将来のメンテナンスと開発を容易にするために、このファイルは「controller」または「view」という名前のパッケージに配置する必要があります。たとえば、プロジェクト関連のルーティングの処理はすべてcontroller/project.pyに配置されます。

Django の組み込み View クラス (ListView、TemplateView など) の使用を優先します。View を自分で実装する必要がある場合は、クラスベースのビューを使用して、さまざまなリクエスト メソッドをさまざまなメソッドにカプセル化することをお勧めします。将来の利便性のためにメソッドを維持します。

2.4 テンプレート

テンプレート ファイルの場合、最適な方法は、さまざまなページと機能をさまざまなテンプレート ファイルに分割し、アプリケーションの名前に従ってフォルダーに保存することです。メンテナンスを行うと、各アプリケーションから対応するテンプレート ファイルをすぐに見つけることができます。

また、テンプレート継承機能を使用することを強くお勧めします。すべてのページは親テンプレートから継承され、さまざまなブロックを使用してページを展開します。各位置のブロック名は親テンプレートで定義されます。 template: 子テンプレートのオーバーライドを提供します。各ブロックには、サイドバー、スクリプト、ヘッダー、main_content、page_title、page_description などの一般的な短い名前を使用することをお勧めします。

コメント ボックスなどの一般的な機能については、別のファイルに保存し、必要に応じて {% include 'filename.tpl.html' %} を通じて読み込むことを検討できます。 extends 命令と include 命令を同時に使用する必要がある場合は、それらをブロック内で使用する必要があることに注意してください。そうしないと無効になります。次の例は無効です:

は次のように使用する必要があります:

パート 3. コーディング スタイル

3.1 docstring

Python 言語の柔軟性により、コードを記述するときに特定のメソッドのパラメーターの型や戻り値の型を忘れてしまうことがあります。この場合、他の人が開発および保守できるように、docstring を使用して各メソッドに明確な情報の注釈を提供する必要があります。 PyCharm を使用している場合は、このリンクを参照して、オートコンプリートの docstring を記述することができます。

3.2 複数の戻り値

多くの場合、メソッドは呼び出し元に複数の値を返すか、JSON を通じてフロントエンドに返す必要があります。データがランダムに返される場合、開発の混乱につながり、最終的にはメソッドが何を返すかさえわかりません。

A better approach is to accept the return format. 呼び出し元に返す場合は、タプルを返し、各値の意味を docstring に書き込むだけです。結果を返すだけでなく、データ処理中に問題や例外が発生したかどうかを示すエラーを返す必要がある場合もあります。一般に、使用可能なメソッドはいくつかあります。

raise を通じて例外をスローする

複数の戻り値 (err、result = func()) を通じて返す

Returnedクラス内の属性を介して、たとえば、instance = Class(); err =instance.error_message

これら 3 つのメソッドには長所と短所があり、プロジェクトの実際の状況に応じて選択する必要があります。どちらを使用しても構いません。両方のメソッドをプロジェクト全体で統一する必要があり、できるだけ混合しないでください。

フロントエンドに返される JSON については、少なくとももう少し複雑にする必要があります。 2 ～ 3 個のフィールドを返す必要があります。

#code は、この呼び出しによって返されるステータス コードであり、実際の状況に基づいて合意することができます。このメッセージは、開発者がデバッグやユーザーへの通知に使用できるステータス コードのわかりやすいメッセージです。 data は実際に返されるデータ情報です。多くの場合、このフィールドは必要ありません。具体的なフィールドの形式も実際の状況に基づいて再度合意する必要があります。

パート 4. ルーティング組織

エレガントでシンプルなルーティングにより、プロジェクトの品質が保証され、メンテナンス コストが削減されます。

4.1 ルーティング システム

Django は、ビジネスのさまざまなニーズを満たすことができる強力なルーティング システムとルーティング アルゴリズムを備えており、構成は柔軟かつシンプルです。各ルーティング構成ファイルは URL PATH to Function /クラスマッピング。フレームワークやその他の制限を受けることなく、すべてを自分で設定できます。 Django のリクエスト ルーティング戦略については、ドキュメントのこのセクションを参照してください。

ルートを構成する際、後で簡単に使用できるように、いくつかの変数を山括弧で囲むことができます。一部の「パス コンバータ」は、山括弧内で使用して、str、int、slug、uuid、path などの変数の型を指定できます。完全な URL ルーティング ファイルは次のようになります:

さらに、re_path を使用してルートに通常の一致を設定することもできます:

場合によっては、一部の URL にデフォルト ルートを追加することができます。たとえば、/blog/ にアクセスするとデフォルト ページが返され、/blog/page にアクセスするとデフォルト ページが返されます。指定されたページ番号のコンテンツを返します。これは次のように構成できます。

4.2 ルーティングに含まれるもの

プロジェクトが拡張し続けると、使用されるルートも今後も増え続けるため、Django はさまざまなアプリでルートを整理しやすくするためのルート包含メカニズムを提供します。簡単な例を見てみましょう:

この例では、community/* を要求するすべてのルートが、解析のために aggregator.urls に渡されます。 contact/* リクエストは、処理のために別のルーティング モジュールにも渡されます。プロジェクトにそれほど多くのアプリケーションがなく、それでもインクルードを通じてルーティングを管理したい場合は、次のメソッドを使用できます:

4.3 名前空間

一般に、各 Django プロジェクトは複数のアプリで構成されています。すべてのアプリ ルートが URLCONF_ROOT に配置されている場合、時間が経つにつれて、このファイルはますます難しくなります。維持する必要があり、非常に混乱します。同じ名前のルートが異なるアプリで使用され、競合が発生する可能性があります。これらの問題を解決するには、「ルートインクルージョン」と「名前空間」を利用することで解決できますが、特に再利用可能なアプリを保守する場合、ルートの一意性を確保するために、名前空間が特に重要になります。

通常、名前空間にはアプリケーション名前空間とインスタンス名前空間の 2 種類があります。たとえば、admin:index は管理名前空間のインデックス ルートを表します。この部分の詳細については、公式ドキュメント

を参照してください。

アプリケーション ネームスペースは理解しやすいです。これはアプリケーション レベルのネームスペースを指します。一般に次のように構成されます:

インスタンス ネームスペースはインスタンスを指しますレベル名前空間は、アプリを複数回インスタンス化する場合によく使用されますが、それぞれのインスタンスを区別するために、インスタンス名前空間を導入する必要があります。公式ドキュメントの例を見てみましょう:

2 つのルート author-polll と Publisher-polls には実際には同じルートが含まれていますが、異なるルートが指定されていることがわかります。名前空間。これはインスタンス レベルの名前空間、つまり現在アクセスされているオブジェクトの名前空間です。異なる URL にアクセスすると、異なるユーザー ID は異なる名前空間を取得します。たとえば、訪問者と管理者の両方が、polls:index で指定されたページにアクセスしますが、名前空間が異なるため、まったく異なる結果が得られます。

以上がDjango開発手法とはの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。