用語はしばしば同じ意味で使われ、明らかにかなりの重複がありますが、システムが ORM であり、それが DAL であることによって暗示されているわけではないと言うことによって、何かが強く暗示されていることが暗示されているように思われることもよくあります。それは何ですか？これらのタイプのシステムを区別する重要なポイントは何ですか?
たとえば、Database、Table、Column、および Row クラスを実装し、既存のデータベースの自動分析によってそれらにデータを入力し、単純化された対話などを可能にするコードがあるとします。外部キーなどのデータベース エンティティ間の構造的な関係を理解し、適用し、活用します。すべてのエンティティ モデルをサブクラス化して、テーブル固有の機能をそれらにロードできます。
これはどの程度 DAL ですか? それはどの程度ORMですか？なんで？
ORM では、アプリケーション内のクラス/オブジェクトはデータベース テーブルと操作にマッピングされ、永続性が確保されます (場合によっては自動的に)。
DAL では、データベース操作はコード ファサードの背後に隠されています。
ORM は、任意のオブジェクトのセットをリレーショナル データベースにマッピングできると思います。一方、DAL はアプリケーションに固有のものであり、他のオブジェクトをサポートするように自然に拡張することはおそらくできません。
それだけでなく、ORMはデータベース エンティティとの間でクラスをマッピングすることに特に関係していますが、DAL はマッピングなしでデータベース内のデータにアクセスするための単なる方法かもしれません。
オブジェクトを保存していないストレージ システムに接続するオブジェクト指向の DAL は、ORM を実装します。ORM は一般的に Hibernate のようなものを意味すると理解されていますが、重要なのはインピーダンスの不一致の処理です。
【拡大】
データ レベルでは、あるタイプ (リレーショナル) のデータを別のタイプ (OO) のデータにマッピングすると、インピーダンスの不一致が発生します。
たとえば、DAL で次のような行を何回見たことがありますか?
db.AddInParameter(dbCommand, "Name", DbType.String, name);
それとも反対側
customerId = Convert.ToInt64(dr["CustomerID"].ToString());
プリミティブ データ型をマッピングするときに、多くの問題が発生します。
オブジェクト レベルでは、DAL は使用する構造を返す必要があります。ある種のビジネス オブジェクトであろうと、単なる生データであろうと。独自の DAL と ORM の両方がこれを処理する必要があります。
設計レベルでは、構築するオブジェクトは格納されたデータを反映しています。したがって、構造上の違いが発生する可能性があります。これらは ORM ソリューション内でも処理されますが、DAL 内で同じことを行う必要があります。たとえば、OO コード内で適切な継承を実装するのはよいことですが、それをリレーショナルなものに簡単に変換することはできません。
ORM は、DAL 内で既に行う必要がある多くのことを自動化する製品をプッシュするために作られた用語であることを指摘したかっただけです。ORM ソリューションは生活を楽にし、多くの品質/パフォーマンス上の利点を提供します。しかし、DAL の主要コンポーネントの 1 つが独自の ORM を作成しているという事実は変わりません。
私がプログラミングを始めたとき、ORMは存在しませんでした。最初の ORM が登場したとき、それらは DAL の作成に使用される外部ツールでした。現在、DAL と ORM は混在しています。そのため、多くの開発者がこの用語を同じ意味で使用しています。
DAL として機能する ORM の最もよく知られた例は NHibernate です。その他の例として、Subsonic と CSLA.NET があります。これらはすべて .NET ツールです。IIRC、ORM ツールは Java の世界で始まりました。他の技術スタックは、Java が行ったことをコピーしました。