ここでの最終的な問題は、どのオブジェクト リレーショナル マッパー (ORM)を使用するかではなく、最終的にそのようなマッパーが何をするかです。この特定のレイヤーは、多くの場合、データ アクセス レイヤー (DAL)にインターレースされます。
ここでの関数は、本質的に互換性のない型間で変換するための手法であることがわかります。基本的に、利用可能な仮想オブジェクト データベースを作成します。このレイヤーの重要性は、ドメイン ロジック/ビジネス レイヤーをデータ アクセス レイヤーまたはオブジェクト リレーショナル マッパーにリンクすることです。これは基本的に、データ構造へのアクセスを必要としないロジックを分離するのに役立ちます。これにより、ユーザー インターフェイス、ドメイン ロジック、およびデータ アクセス レイヤー間の分離がより一貫したものになります。
インターフェースは、データ層がデータ構造にどのように話しかけているかを知りません。現在、私はデータ アクセス レイヤーとオブジェクト リレーショナル マッパーを類似性のために混在させていますが、それらはまったく異なります。
データ アクセス レイヤーとオブジェクト リレーショナル マッパーの違い
オブジェクト指向言語とリレーショナル データベース間の従来の交換技術と比較して、オブジェクト リレーショナル マッパーは多くの場合、記述する必要があるコードの量を削減します。この利点は明らかですが、大きな落とし穴があります。何が起こっているのかを過度に抽象化する傾向があり、実際に何が起こっているのかがわかりにくくなります。
考慮すべきもう 1 つの点は、 ORMに過度に依存すると、設計の不十分なデータベースが生成される可能性があることです。
図からわかるように、これがObject Relational Mapperの背後にある理論です。N層アーキテクチャまたはサービス指向アーキテクチャ内でよく見られるデータアクセス層として。
両者の主な違いは次のとおりです。
オブジェクト リレーショナル マッピング ツールは、アクティブなレコード モデルに従って、この方法でデータ レイヤーを提供します。ORM/アクティブ レコード モデルは、Web フレームワークで人気があります。
データアクセスレイヤーは、ある種の永続ストレージに保存されたデータへのアクセスを簡素化するレイヤーです。データ アクセス層を使用するアプリケーションは、データベース サーバーに依存する場合と独立する場合があります。データ アクセス レイヤーが複数のデータベース タイプをサポートしている場合、アプリケーションは、DAL が通信できるすべてのデータベースを使用できるようになります。いずれの場合でも、データ アクセス レイヤーを使用すると、データベースへのすべての呼び出しを集中的に行うことができるため、他のデータベース システムへのアプリケーションの移植が容易になります (データベースとのやり取りの 100% が特定の DAL で行われると仮定した場合)。応用）。
類似点と相違点はわかりましたが、データ構造はどうでしょうか。データベース内で強制されますか? 短い答えはノーです。次の選択肢があります。
- リレーショナル データ: より伝統的なデータベースアプローチを使用します。
- NoSQL: NoSQLアプローチ に従うオブジェクト リレーショナル マッパー* が登場しました。
これにより、プロジェクトの要件に基づいて柔軟性が向上します。Stack Overflowに関する素晴らしい質問には、実際にはNoSQLアプローチを使用した現実世界があります。（ここ）
大きく異なる 4 つのメリットは次のとおりです。
生産性: 通常、データ アクセス コードは一般的なアプリケーションの重要な部分を占めており、そのコードを記述するために必要な時間は、開発スケジュール全体の重要な部分を占める可能性があります。ORM ツールを使用する場合、コードの量が減ることはまずありません (むしろ増える可能性もあります) が、ORM ツールは、定義したデータ モデルに基づいて、データ アクセス コードの 100% を自動的に生成します。
アプリケーション設計:非常に経験豊富なソフトウェア アーキテクトによって設計された優れた ORM ツールは、アプリケーションで優れたプログラミング手法を使用することをほとんど強制する効果的な設計パターンを実装します。これにより、関心事の明確な分離と独立した開発がサポートされ、アプリケーション レイヤーの並列同時開発が可能になります。
コードの再利用:クラス ライブラリを作成して、ORM で生成されたデータ アクセス コード用の別の DLL を生成すると、さまざまなアプリケーションでデータ オブジェクトを簡単に再利用できます。このように、クラス ライブラリを使用する各アプリケーションには、データ アクセス コードがまったく必要ありません。
アプリケーションの保守性: ORM によって生成されたすべてのコードはおそらく十分にテストされているため、通常は広範なテストについて心配する必要はありません。明らかに、コードが必要な機能を確実に実行する必要がありますが、広く使用されている ORM では、すべてのスキル レベルの多くの開発者がコードを叩く可能性があります。長期的には、アプリケーションによるデータ オブジェクトの使用方法に影響を与えることなく、データベース スキーマまたはモデル定義をリファクタリングできます。
アプリケーションがテストされたからといって、それ以上テストしたり、改善したりできないわけではないため、明らかにそれらを一粒の塩で取ってください。
オブジェクト リレーショナル マッパーの大きなリストを見つけることができます。
これらは入手可能な大量のほんの一部であり、リストへのリンクです。素晴らしいものもあれば、そうでないものもあります。 最終的な目標は、希望するアプリケーションの目標に密接に準拠するものを見つけることです。
うまくいけば、それは本当にあなたを助けます.