這些術語通常可以互換使用，而且有明顯的重疊，但同樣往往似乎意味着人們認爲某個系統是一個ORM並不意味着它是一個DAL，從而強烈暗示某些東西。那是什麼？如果有的話，什麼是區分這些類型系統的關鍵點？例如，假設我有一些代碼實現了Database，Table，Column和Row類，通過自動分析現有數據庫來填充它們，允許簡化交互等。它瞭解，執行和利用數據庫實體之間的結構關係，例如外鍵。所有的實體模型都可以被分類以將表特定的功能加載到它們上面。DAL和ORM之間的界限在哪裏？
這是DAL的程度如何？它在多大程度上是一個ORM？爲什麼？
在一個ORM，在應用類/對象被映射到持久性的數據庫表和操作，有時自動地。
在DAL，數據庫操作後面的代碼門面隱藏。
我認爲ORM能夠將任何一組對象映射到關係數據庫;而DAL特定於您的應用程序，並且可能無法自然延伸以支持其他對象。
不僅如此，ORM特別關注將類映射到/從數據庫實體，而DAL可能只是一種方式讓您訪問數據庫中的數據，而無需任何映射。
當我開始編程時，ORM不存在。當第一個ORM出來時，它們是用來創建DAL的外部工具。現在，DAL和ORM混合在一起了。這就是爲什麼很多開發者可以互換使用這些術語。
作爲DAL運行的ORM最着名的例子是NHibernate。其他的例子是Subsonic和CSLA.NET。這些都是.NET工具。 IIRC，ORM工具始於Java世界。其他技術堆棧則複製了Java所完成的工作。
任何面向對象的DAL連接到任何不保存對象的存儲系統都會實現一個ORM。 ORM通常被理解爲像Hibernate，但重要的是處理阻抗不匹配。
[EXPANDED]
在數據電平時要映射的一種類型（關係）的數據到另一個（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的主要組件之一是創建你自己的ORM。
@chaos - 爲什麼行話標籤？ DAL和ORM是非常好的技術縮寫 – 2009-02-25 23:48:25
@DJ：我不是故意用術語來暗示這些術語存在某些錯誤*。正如另一位旁觀者所建議的Rich B的怪異的代言仇恨，我試圖以http://en.wikipedia.org/wiki/Jargon爲指導。 – chaos 2009-02-25 23:52:06
計算機術語可以被外界稱爲專業術語 - 但我們這裏的所有軟件專家 - 這不是我們的行話 - 否則幾乎每個帖子都必須標註行話 – 2009-02-26 00:05:35