業務對象和數據層

Question

這個網站為我提供了許多有用的答案，但是經過一個小時的搜索，我找不到任何能夠滿足我需求的東西。 所以這里......

我正在為之工作的公司正在設計新的業務對象層和數據訪問層 - 這些將駐留在單獨的程序集中。

問題是我很難理解這兩層之間的交互 ​​- 特別是，如果DAL知道BOL，我已經讀過許多文章說過依賴順序應該是這樣的：

GUI /演示 - > BOL ---> DAL

但據我所知，DAL需要引用BOL才能將對象'返回'到BOL層。

我要在BOL和DAL之間進行中間組裝，它基本上是一個薄層，里面裝有接口來解耦這兩個DLL，因此如果需要，框架可以使用不同的DAL。

這讓我想到引入另一個薄層，其中包含BO實現的一堆接口，然后當BOL調用DAL接口時，它傳遞一個實現其中一個BO接口的對象，然后DAL繼續填充賓語。 這消除了BOL和DAL之間的所有依賴關系 - 但是，我發現很難證明它是誠實的。

理想情況下，我們希望使用ORM，因為它只是刪除了編寫CRUD內容的需要，但我們的客戶習慣於在數據庫中擺弄列長度，這是我們使用強類型DataTables迄今為止的大多數錯誤的原因。 。 我聽說Linq2SQL也在編譯時存儲列長度，不確定NHibernate是否存在（但是，我不確定我們的數據庫模式是否為NHibernate設計得足夠干凈，處理遺留系統的陷阱）。

所以，對BOL和DAL之間關系的任何見解都會非常受歡迎 - 如果上述內容寫得不好，請致歉，如果有人需要澄清，我會樂意提供更多詳細信息。

馬龍

Answer 1

我這樣做的方式是BO期望DataReader或DataContext或者來自DAL的任何東西，而不是實際形成的對象。 然后，BO層的工作是從回來的對象中獲取並填充自己。 DAL沒有返回完成的BO。 要記住的主要事情是，在BO層中更改某些內容不應該導致DAL層出現問題，但是更改DAL層中的某些內容可能會導致BO層出現問題。

我通常做的一個簡短例子

在BO層

FillData(){
   DataReader dr = DataLayer.GetData("SomePropertyForAStoreProcedure");
   If dr.Read(){
    Property1 = dr.GetValue("Property1");
    //So on and so forth
   }
}

在DAL中

DataReader GetData(String SPProperty){

}

Answer 2

看看SubSonic http://subsonicproject.com/它為大多數數據訪問繁瑣的工作，它比大多數ORM更容易

Answer 3

DAL需要對BOL的引用，以便它可以填充對象。 您不希望有的是從BOL返回到DAL的任何引用或耦合 - 這樣做會導致您的BOL耦合到特定的數據庫實現。 當你考慮它時，這是有道理的。 您的DAL知道業務對象的詳細信息，直到屬性級別以及如何從數據庫中檢索數據 - 當然DAL本質上與BOL緊密耦合。 所以參考方式很好。 如果你考慮一下另一方面是什么？ 數據庫。 從您的對象數據到數據庫的“緊密耦合”？ 是的，它非常緊張。 這個概念甚至沒有多大意義。

這是你需要解耦的另一個方向。 所以，只要沒有從DAL到BOL的直接耦合，您可以隨意更改數據平台。

在這種情況下，為BO創建接口並將它們傳遞給DAL沒什么意義。 但是，您有時可能需要采用其他方式。 通常，業務對象不應該知道有關如何創建或持久化它們的任何信息。

實際上，即使對於大多數ORM，例如，創建完全沒有任何類型的持久性工件的業務層可能變得非常困難，有時實際上是不可能的。 所以偶爾你會遇到一些難以解決的事情，你可能會發現嚴格避免在BO中擁有任何數據知識會導致你過度復雜而不是增加價值。

如果您覺得沒有更好的方法，並且您需要在BOL中保留一些內容，請創建一個簡單的界面，以便將DAL功能傳遞給BOL。 這樣，您至少可以將BOL與特定數據庫實現分離。

此外，雖然這是一個額外的工作，除非這是一個非常簡單的一次性應用程序，我強烈建議您在UI和BOL之間添加另一個層。 MVP（Model-View-Presenter）模式是一種通用設計模式，用於減少核心應用程序和UI之間的耦合。 演示者有很多變種，不要過於關注具體的細節，如果你從未使用它，只需從簡單的MVP開始。

模式並不那么難，只是UI本身是如此混亂，以至於在你覺得你在任何時候編寫的代碼系統地和有條不紊地努力解耦之前，你可能至少需要幾個主要的迭代/應用程序。 UI。 只要繼續努力，開始掌握各種技術，並且不要因為你真的沒有實現清晰的分離這一事實。 您學到的任何東西都可以做到這一點，甚至可以為在UI上創建一個明確定義的邊界做出一點貢獻，這是朝着正確方向邁出的重要一步。

Answer 4

“正確”的方法將根據業務需求而變化。 說實話，有很多項目讓我覺得舊式的ado記錄集比現在的許多ORM產生更少的開發時間並且更容易維護。 花些時間確定您的需求，並記住開發時間和可維護性是設計目標，也應該適當權衡。

Answer 5

它還取決於您使用的/ /庫/ ORM（對象關系映射器）。 當使用（好）ORM時，DAL應該是一個非常遙遠的問題，因為它幾乎被ORM完全隱藏; 但是，最佳實踐要求即使在那時，對於中型到大型應用程序，也應該在BOL和ORM之間引入另一層，通常是DTO（數據傳輸對象）。 DTO也可以在沒有ORM的情況下使用，因為它們只是在單獨的庫中定義的啞對象，並且DAL可以負責持久化它們（將它們從/向數據庫結構轉換），而BOL可以查詢DAL並接收這些對象。

可以以各種方式實現層的分離，最常見的是通過接口和/或MEF或另一個DI / IOC框架。 如果有效地使用，任何這樣的技術都實現了足夠的解耦。

此外，正如Sisyphus所說，取決於所使用的技術，其中一個分層架構模式將有助於很好地分離關注點：MVC，MVP，MVVM等。我個人推薦使用WPF（桌面）或Silverlight（web）的MVVM但我很高興有偏見 - 即我喜歡他們兩個人去死:)

Answer 6

這是我的發現，
1.使用接口
2.在DAL和BLL之間使用DTO [數據傳輸對象]
3.將BLL分成兩部分，
a. BLL
b. Service Layer
4.使用控制反轉（IoC）容器使耦合保持盡可能低。