BLL和DAL

Question

解決方案的設置之間的通信：

• DAL（類庫）
• BLL（類庫）
• 通用（類庫（一些常用的功能 - 枚舉，日誌，異常.. 。））
• 應用1（Windows應用程序）
• 應用2（Windows應用程序）
• Web應用程序（Web應用程序）
• ...

比方說，我有一個客戶實體，它是：

• 在SQL服務器
• 一個CustomerDataTable在DAL
• 一個Customer類BLL表
• a BLL.Customer class in all the applications

什麼樣的對象應該BLL和DAL用於通信的 - DataTable或List<Customer>（例如）？在第一種情況下，BLL邏輯應該將Customer對象轉換爲DataTable並將其發送給DAL。在secod情況下，DAL層應該知道Customer類，它位於BLL層中。但原始的DLL引用DAL而不是相反...

我應該把所有的類放入單獨的程序集，它被所有其他程序引用（Common，BusinessObjects，...）嗎？在這種情況下，我可以在我的所有項目中使用Customer類。

當我知道時，我應該甚至打擾分離DAL和BLL，只有一個BLL會使用我的DAL。在這種情況下，我可以將它們合併爲一個項目。

PS - 我正在閱讀有關數據表，很多人說，我們不應該使用它們。什麼是更好的選擇？也許是時候讓我學習一些ORM映射工具:)

Answer 1

在我看來，你應該有另一層（單獨DLL）。像「域名」一樣，您將在哪裏保留像客戶這樣的所有實體。然後在這個程序集的層次結構中簡單地包含所有更高級別（DAL，BLL，UI和其他）。

採樣架構可以是這樣的：

（數據庫）< - > DAL < - > BL < - > UI

，並在各個層面，你將有機會獲得 「域」 層。 DAL應該返回List而不是DataTable。在某些階段，您可能希望在DAL中使用像NHibernate一樣的OMR開發流程，也可能會返回一個List。

Answer 2

我會使用以下模式，因爲它允許您稍後升級到不同的持久性策略。

UI/Consumer <--- (view models) --> BLL <--- Models ----> DAL/Persistence 

這裏，視圖模型在BLL之外消耗，模型在BLL/DAL層之間通信。

在你的情況下，模型可以是任何的DAL使用 - 例如數據表或更高版本或許ORM實體。 BLL負責模型和視圖模型之間的映射。

至於保留類型在他們自己的程序集 - 是視圖模型，併爲了保持一致性，對於模型也是。

保持模型和視圖模型單獨停止BLL之外的持久性策略泄漏，從而允許將來的設計更改爲持久性。

這種分離的一個優點是不同的視圖模型使用者對於相同的持久性模型/實體可以具有不同的視圖模型。有些可能很小，屬性很少，其他功能也很豐富。它還允許您引入脫機/斷開功能，因爲視圖模型可以在不同的時間返回，從而允許您決定數據合併策略。這也允許你持久化實體（例如表的增長和改變形狀）。因爲這看起來像一個.net實現像AutoMapper將提供很多開箱即用的功能

當然，這可能是對你的應用程序的矯枉過正 - 但我仍然保持一個BLL映射，只談論視圖模型給所有BLL消費者。這應該給你足夠的解耦。

Answer 3

將領域實體推入dal是一個選項，可以刪除crcular依賴項，但可能與您的意圖不符。但這並不是聞所未聞的;例如LINQ到SQL的實體會存在於DAL中。

其他選項：

• 把它們放到一個共同的下組件（但可能會留下您的BL而空）
• 使用IOC刪除/反向BL/DAL之間的參考

這裏沒有單一的正確答案。

Re DataTable;個人我同意 - 我不是粉絲;）但是，他們可以成功和合理地使用。但是，如果我有使用它們，我會將它們保留在DAL中作爲實現細節 - 而不是將它們暴露於此。

Answer 4

很難回答這個普遍問題，而不知道應用程序域是否足夠好。 我會先考慮未來變化的最可能發生地點，並試圖從需要靈活性的地方找出答案。

我以下的想法只是一個建議。隨時考慮他們，改變/忽略你覺得無關緊要的事情。

從BLL分離DAL幾乎總是一個好主意。數據方案是應該從應用程序的其餘部分封裝和隱藏的一件事，因此請將DataTable，DataSets，ORM或任何其他解決方案隱藏在DAL中。 BLL（以及它上面的層）應該使用簡單的數據類型（意思是簡單的類）。我認爲將這些類放在Model類庫中是一個好主意，該類庫沒有引用並且可以在任何地方使用。

它感覺你有點太多分層......你真的需要BLL中的Customer類和應用層中的另一個嗎？可能會，但我會確保並考慮兩次。

從我在我最近的項目（一個天氣網站每天200K唯一訪問者）的一個經驗，我們使用link2sql數據訪問（主要是隻讀數據），以及簡單的數據類都在我們ASP.Net MVC應用程序（當然作爲模型/視圖模型的一部分）。它工作得非常順利，我們可以輕鬆地更改數據方案而不會打破其他層。

至於你最後一個關於DataTables的問題，這些對象，如果你決定使用它們（我會投反對票），只屬於你的DAL。他們不應該暴露於其他層，因爲這會創建耦合到特定的類。如果明天MS發明更好的課程怎麼辦？你現在是否可以切換到你的項目中有大量的引用到DataTables，它的方法和屬性？如果將DAL更改爲NewAwsomeDataTable類，並且其他應用程序非常無知，則更好。

希望幫助:)