我正與同事討論在新應用程序中實現數據層的最佳方式。數據層最佳實踐
一個觀點是數據層應該知道業務對象（我們自己的代表實體的類），並且能夠本身處理這個對象。
相對的觀點是數據層應該是對象無關，純粹和簡單處理的數據類型（字符串，布爾變量，日期等）
我可以看到，這兩種方法可能是有效的，但我的自己的觀點是我更喜歡前者。這樣，如果數據存儲介質發生變化，業務層不必（必然）不得不改變以適應新的數據層。因此，從SQL數據存儲轉換到序列化的xml文件系統存儲是一件微不足道的事情。
我的同事的觀點是，數據層不應該知道對象定義，只要數據被恰當地傳遞，就足夠了。
現在，我知道這是有可能發起宗教戰爭的問題之一，但我很感謝來自社區的關於如何處理這些事情的任何反饋。
TIA
這真的取決於你對世界的看法 - 我曾經是在非聯合陣營。 DAL只在那裏向BAL提供數據 - 故事結束。隨着Linq to SQL和Entity Framework等新興技術越來越流行，DAL和BAL之間的界限已經模糊了一些。在L2S中，尤其是您的DAL與業務對象緊密耦合，因爲對象模型與您的數據庫字段具有1-1映射關係。
與軟件開發中的任何事情一樣，沒有正確或錯誤的答案。您需要了解您的要求和未來要求，並從那裏開展工作。我不會在達喀爾拉力賽上使用法拉利，因爲我會在賽道上駕駛攬勝。
一個很好的書我都有，涵蓋這個話題，是Data Access Patterns，克利夫頓諾克。它已經得到了很多關於如何將業務層與持久層分離的很好的解釋和好點子。你真的應該試試看。這是我最喜歡的書之一。
我發現得心應手的一招是將我的數據層設置爲「不可知的集合」。也就是說，無論何時我想從我的數據層返回一個對象列表，我都會讓調用者通過列表。因此，而不是這樣的：
public IList<Foo> GetFoosById(int id) { ... }
我這樣做：
public void GetFoosById(IList<Foo> foos, int id) { ... }
這讓我傳遞一個普通的老名單，如果這就是我所需要的，或者更智能的實現IList的<牛逼>（像ObservableCollection <T>）如果我打算從UI綁定到它。這種技術還可以讓我從方法返回東西，比如包含錯誤消息的ValidationResult（如果發生的話）。
這仍然意味着我的數據層知道我的對象定義，但它給了我一個額外的靈活性。
查看Linq to SQL，如果我現在正在創建一個新的應用程序，我會考慮依賴完全基於Linq的數據層。
除此之外，我認爲儘可能地去耦合數據和邏輯是一種很好的做法，但這並不總是實用的。邏輯和數據訪問之間的純粹分離使連接和優化變得困難，這正是Linq如此強大的原因。
你可以擁有兩者。讓數據層不知道您的業務對象，並使其能夠處理多種類型的數據源。如果您提供用於與數據交互的通用接口（或抽象類），則可以爲每種類型的數據源提供不同的實現。工廠模式在這裏很好。
Jeffrey Palermo寫了一篇關於此的好文章。他稱之爲Onion Architecture。
在我們使用NHibernate的應用程序中，答案變成了「介於兩者之間」，因爲XML映射定義（它們指定哪個表屬於哪個對象以及哪些列屬於哪個字段等）顯然在業務對象層。
它們被傳遞給通用數據會話管理器，該管理器不知道任何業務對象;唯一的要求是傳遞給CRUD的業務對象必須具有映射文件。
舊的帖子，但尋找類似的信息我碰到this這很好地解釋它。
我完全同意。數據訪問層等的設計變得相當模糊。而我會一直選擇將業務邏輯與表示層分開。 MVC模式FTW ;-) – 2012-08-26 17:58:21