Django で推奨されるソフトウェア アーキテクチャは、すべてのビジネス ロジックとデータ アクセスをモデルに入れることです。
しかし、一部の同僚は、データ アクセス レイヤーをビジネス ロジック (ビジネス サービス レイヤー) から分離する必要があると提案しています。その理由は、別のデータ ソースが使用されている場合、データ アクセス レイヤーが変更を分離できるからです。また、複数のモデルに存在できるビジネス ロジックがあるとも言っています。
しかし、個別のデータ アクセス レイヤーとビジネス ロジック レイヤーを使用してコーディングを開始すると、データ アクセス レイヤーは単純 (基本的には db スキーマを定義するモデル コード) であり、あまり価値がないように見えます。
djangoモデルからデータアクセスを分離することに本当に価値はありますか、それともdjangoはすでにORMで十分なデータアクセス層を提供していますか?
かなりの数の django アプリを実装した開発者を探しており、彼らの意見を聞いています。これは、小規模から中規模の Web アプリ用です。
Django の開発に 3 年間携わった後、私は次のことを学びました。
ORM はアクセス層です。これ以上は必要ありません。
ビジネス ロジックの 50% がモデルに含まれます。これの一部は、フォームで繰り返されたり増幅されたりします。
ビジネス ロジックの 20% は Forms で行われます。たとえば、すべてのデータ検証はフォームにあります。場合によっては、フォームは一般的なドメイン (モデルで許可されている) を、問題、ビジネス、または業界に固有のサブセットに絞り込みます。
ビジネス ロジックの 20% は、アプリケーション内の他のモジュールに組み込まれています。これらのモジュールは、モデルとフォームの上にありますが、ビュー関数、RESTful Web サービス、およびコマンドライン アプリの下にあります。
ビジネス ロジックの 10% は、管理コマンド インターフェイスを使用してコマンドライン アプリに組み込まれています。これは、ファイルの読み込み、抽出、およびランダムな一括変更です。
ビュー関数と RESTful Web サービスがほとんど何もしないことが非常に重要です。モデル、フォーム、およびその他のモジュールを可能な限り使用します。ビュー機能と RESTful Web サービスは、気まぐれな HTTP とさまざまなデータ形式 (JSON、HTML、XML、YAML など) の処理に限定されています。
Yet Another Access Layer を発明しようとすることは、価値のない演習です。
答えは、アプリケーションの要件によって異なります。
常にリレーショナル データベースを使用し、特定の ORM と結合できるアプリケーションの場合、データ アクセスとモデルを分離する必要はありません。Django ORM は、データ アクセスとモデルが一緒であることを前提とするアクティブ レコード デザイン パターンに基づいています。長所はシンプルさ、短所は柔軟性が低いことです。
データ アクセスとモデルの分離は、開発者がデータ アクセス レイヤーとビジネス ロジックを完全に切り離したい場合にのみ必要です。データマッパー設計パターンでそれを行うことができます。SQLAlchemy などの一部の ORM は、この設計パターンをサポートしています。Pro は柔軟性が高く、Con はより複雑です。
詳細については、Martin Fowler 著の「Patterns of Enterprise Application Architecture」という本をお勧めします。