編集：
[MVC] タグと [design-patterns] タグを追加して、この質問の対象者を拡大しました。これは、Python や SQLalchemy に直接関係するものではなく、一般的なプログラミングの質問であるためです。これは、ビジネス ロジックと ORM を備えたすべてのアプリケーションに適用されます。
基本的な質問は、ビジネス ロジックを個別のモジュールに保持する方がよいか、ORM が提供するクラスに追加する方がよいかということです。
作業する構造をセットアップする必要があるフラスコ/sqlalchemy プロジェクトがあります。セットアップ方法については 2 つの有効な意見があり、プロジェクトが実際に開始される前に、そのうちの 1 つに決心したいと思います。彼ら。
2 つのうちどちらがより理にかなっているのか、その理由、および利点と欠点は何かについて、洞察を提供していただける方がいらっしゃいましたら、大歓迎です。
私の例は、一括して送信したり、1 人のユーザーに表示したりする必要がある HTML レターです。レターには、宛先のユーザー向けの請求書や記事のリストを表示するセクションを含めることができます。
方法 1:
コードを 3 つの層に分割します。1 層目: Web インターフェイス、2 層目: 文字の処理、3 層目: ORM (sqlalchemy) からのモデル。
Web サイトは、第 2 層のクラスでサーバー側メソッドを呼び出します。第 2 層は、このレターを取得する必要があるユーザーをループし、HTML を生成してレター内のいくつかの一般的なフィールドを置き換える内部メソッドを持ちます。現在のユーザーの情報。また、請求書またはレターに配置する記事のリストを生成する内部メソッドもあります。
この方法では、第 3 層はデータベースからデータを取得するためだけに使用され、ユーザーの名と姓から氏名を生成するなどのデータベース関連のロジックに使用される可能性があります。2 番目の層は、ほとんどの作業を実行します。
方法 2: コードを同じ 3 つの層に分割しますが、2 番目の層のユーザーのコレクションに対してのみループを実行します。
HTML、請求書、および記事のリストを生成するためのメソッドはすべて、ORM が提供する層 3 のモデル定義にメソッドとして追加されます。第 2 層はループを実行しますが、実際の機能は第 3 層のモデル クラスに含まれています。
どちらの方法も機能する可能性があり、どちらにも長所と短所があると結論付けました。
方法 1:
- ビジネスロジックをデータベースアクセスから完全に分離
- ORMモデルをインポートすると、必要のない多くのメソッド/機能もインポートされるのを防ぎ、モデルクラスのコードをよりコンパクトに保ちます。
- テストのためにORMモデルをモックアウトするときに使いやすいかもしれません
方法 2:
- DjangoがPythonで行う方法と一致しているようです
- メソッドへの簡単なアクセスを許可します。モデル インスタンスが存在する場合、それが実行する関数をすぐに呼び出すことができます。(私の例では、letter-instance が利用可能な場合、そのレターの HTML を生成するメソッドを直接呼び出すことができます)
- すべての適切なメソッドを手元に置いて、インスタンスを渡すことができます。