django再構成からflaskへの経験(二)
1647 ワード
プロジェクトは最初から両者に非常に大きな設計の違いがあることに注目しなければならない可能性があります.djangoは自分の内部ですべてのグローバル変数を包装し、エンジンなどのインストールや導入でいいです.しかしflaskのappなどの各種プラグインはいずれも1つ1つのプラグインライブラリであるため、プロジェクトで初期化され、その後のグローバル化も自分で参照して解決しなければならない.
しかしpythonのflaskでは、依存性に問題が発生しやすく、プロジェクトファイルをimportできないか、導入後、定義したすべてのプロパティがありません.
flask web開発-pythonベースのwebアプリケーション開発実戦でも言及されていますが、簡単なflask開発では、python初期化ファイルに青い本が一般的に置かれています.
最後の文の
この問題はEffective Pythonでも言及されていますが、pythonがモジュールを導入すると、以下の操作が深さ優先の順序で実行されます.はsys.pathが指定する経路のうち、探索導入モジュール は、モジュールからコードをロードし、 が正しくコンパイルされることを保証する.モジュールに対応する空のオブジェクト を作成する.この空のモジュールオブジェクトをsysに追加する.modules内 モジュールオブジェクトのコードを実行し、その内容を定義する .
多くの場合、import viewsを最後の文に置いて前に置かないと、viewsテキストにmainが使用されているため、空のmainファイルが導入され、main変数も存在しないはずです.
このような比較的簡単な問題を除いて、私が直面した問題の導入プロセスは多分です. init app,db views に導入 views views用の各種tools を導入 tools(データベースの検索を含むがこれに限定されない) データベースdb に導入 dbこの時点では、どのような問題があるかがわかります.最初のステップが完了していませんが、ずっと深く実行すると、最初のステップが初期化されているオブジェクトに遭遇し、インポート依存全体に問題が発生します.
この依存を避ける方法は3つくらいあります導入順序 を調整する.は、まずメソッドを導入し、次にメソッドで構成し、 を実行する.動的導入 しかしflaskの特殊性のため,再構成コードは基本的に考慮されず,導入が必要であり,順序も中大規模なプロジェクトでは調整しにくい.私が今臨時に使っているのは、動的導入です.ファイル全体に導入するのではなく、viewsとtoolsの導入関係をviews関数にパッケージします.しかし、importのオーバーヘッドも少なくないため、プロジェクト全体が遅くなる可能性があります.
だから、後で最適化するときに、ツールを工場関数にパッケージして同じ呼び出しを行う必要があります.
またappの位置は、後で問題を避けるために、私も直接プロジェクトの外層にhandle_を作成しました.init.py appとdbの初期化プロセスを格納します.
しかしpythonのflaskでは、依存性に問題が発生しやすく、プロジェクトファイルをimportできないか、導入後、定義したすべてのプロパティがありません.
flask web開発-pythonベースのwebアプリケーション開発実戦でも言及されていますが、簡単なflask開発では、python初期化ファイルに青い本が一般的に置かれています.
from flask import Blueprint
main = Blueprint('main',__name__)
from . import views,errors
最後の文の
__init__.py
は依存の問題を避けるためだ.この問題はEffective Pythonでも言及されていますが、pythonがモジュールを導入すると、以下の操作が深さ優先の順序で実行されます.
多くの場合、import viewsを最後の文に置いて前に置かないと、viewsテキストにmainが使用されているため、空のmainファイルが導入され、main変数も存在しないはずです.
このような比較的簡単な問題を除いて、私が直面した問題の導入プロセスは多分です.
この依存を避ける方法は3つくらいあります
だから、後で最適化するときに、ツールを工場関数にパッケージして同じ呼び出しを行う必要があります.
またappの位置は、後で問題を避けるために、私も直接プロジェクトの外層にhandle_を作成しました.init.py appとdbの初期化プロセスを格納します.