如何拆分數據層和業務對象層，每個層的適當職責是什麼？

如果有分層這樣的商業應用的一條線，這會是勞動力的適當分工：如何拆分數據層和業務對象層，每個層的適當職責是什麼？

數據訪問

調用只有存儲過程，映射的DTO的屬性到用於填充ADO.NET命令的參數集合的散列表tablse。
僅參考SqlDataClient的程序集。
重要的邏輯處理什麼意味着空白，null和空的映射代碼，但其他方面沒有驗證或其他領域特定的邏輯。

所謂業務邏輯

拆分多個結果集成單獨的數據表，例如

公共無效ReturnNthRecordSetFromStoredProcFoo（）
穿過用於數據集的數據訪問，例如

公共無效ReturnDataSet（字符串名稱）{ 回報（新PersonController）.GetAnotherDataSet（名）;}
一個DataTable的一列映射到一個DTO小號
重大邏輯處理什麼樣的手段空白，空，並在映射代碼中爲空。
保留事務對象，儘管它專門用於包裝單個存儲過程調用。
不必SqlDataClient的引用，所以它不能使用SqlDataReaders填寫的DTO
沒有提到的System.Web.UI
授權規則，但在其他方面沒有域特定的邏輯。

2路數據到ASP.NET形式的DTO的結合。
驗證控件屬性 - 通常不直接對DTO進行驗證
通過將DataSets綁定到網格來導航「集合」。事實上試圖與藏品做任何需要的UI遍歷數據行的數據表，瞭解相應的列名是什麼（這是一般只有一種 - 的 - 類似的DTO）

這樣的問題，最後 - 在此應用程序中，數據訪問層是否應將所謂業務層的職責合併？這不是已經是一個兩層，（差不多一個！）應用程序，除了一個額外的程序集的不便之處？

附加信息：好吧，我已經知道應用程序服務器將是一臺機器，可能永遠都是，因爲它是一個低用戶數的Intranet應用程序。所以我不知道要設計物理上獨立的應用程序層。另外，它可能只支持一個UI，並且如果它需要支持除ASP.NET以外的其他功能，則會被完全廢棄 - 另一個經常被引用的層/層的原因。

來源

2009-07-31 MatthewMartin

請參閱我的迴應： http://stackoverflow.com/questions/549305/how-to-handle-communication-between-the-domain-and-database-layers/1209765#1209765 別如果你喜歡我的想法，不要忘記註冊。 – 2009-07-31 11:46:17

聽起來，層之間的責任有點混亂。數據層聽起來相當標準。（「所謂的」）業務層是事物混亂的地方。

在業務層的一些想法：

似乎有大量的數據表示。你提到數據表，數據集，數據傳輸對象。整個應用程序的標準方法會更好。
具有像ReturnNthRecordSetFromStoredProcFoo和ReturnDataSet這樣的名稱的業務層方法沒有意義，也沒有爲業務服務提供適當的抽象級別。（也許這些只是應用程序中選擇不好的示例？）
通常，業務層提供的不止是DataSet傳遞。業務層應該關注驗證，業務規則，安全性甚至審計（儘管有些人喜歡在數據庫中這樣做），而不是處理映射，空值等。
儘管業務層只調用單個存儲過程，但我對業務層中的事務控制沒有任何問題。業務層應該控制事務，以便多個數據對象都可以參與同一個事務（甚至可以跨越不同的數據庫）。即使現在只有一個調用，如果您將來需要添加更多調用，這將很容易，並且不會導致將事務控制改進爲您的應用程序。
我認爲依賴關係正常 - 沒有引用業務層中的Web.UI或SQLClient。
授權規則也可以。我會擴大到包括安全而不僅僅是授權。另外，我沒有看到任何商業邏輯 - 只是好奇商業邏輯是否在存儲過程中？如果我要猜測，我會說是的，因爲每個業務方法只調用一個存儲過程。如果是這樣，那麼對我來說這是一個很大的不行。

我不會結合業務和數據層。我更願意將業務邏輯層和數據訪問層分開。考慮到將它們結合起來並試圖將責任分開一點，我會傾向於後者。

但是，看到這是一個現有的應用程序的問題，我會採取更務實的觀點。一切都伴隨着成本，重要的是要確定正在做什麼變化，變化的努力和風險是什麼，變化的好處是什麼，以及這些變化將如何影響測試周期。

需要思考的其他問題包括：您想要解決的主要問題是什麼？它們是否有效（例如缺陷，缺乏穩定性）？或性能相關？還是建築？或者可能與可維護性有關 - 您是否需要添加新功能但難以發現？你有時間表還是預算？如果你可以回答一些這些問題，它可能有助於指導你。

來源

2009-07-31 04:39:04

我期望看到你所描述的業務層作爲數據層類型的東西。我希望我的數據層能夠保護我免於擔心空值和這樣的事情。我也希望我的業務層包含更抽象的業務規則和概念。例如，如果「組」是「用戶」的集合，我希望看到業務類型功能可以將這些用戶作爲高級別組的一部分來操縱這些用戶。例如，可能會爲該組的所有成員分配權限，或者允許UI級別將這些策略應用到作爲組成員的用戶。我不希望看到那些試圖隱藏所有來自數據庫的事實的函數。我希望這是有幫助的。

來源

2009-07-31 02:39:18 Jon

根據您的服務器負載應該確定物理層的數量。邏輯層的數量實際上更多是個人選擇。

在我們的組織中，我們使用CSLA framework。它是一個業務對象框架，致力於使數據綁定的UI易於使用和維護，同時提供數據層的靈活性。

我不會深入這裏深入，因爲它會更好地爲您自己確定該框架是否值得您使用，但不用說，它有它自己的SafeDataReader類，它佔到了空值，無需使用數據集。

它的「dataportal」（文章較舊，但仍然相關）允許您輕鬆地將數據訪問移動到其自己的層，並且不需要更改代碼。

DNRtv有一些視頻pod演員，CSLA的設計者Rockford Lhotka展示了示例應用程序的工作原理。 Part 1和Part 2。

節目每個只有一個小時，可能可以幫助您決定它是否適合您使用。

來源

2009-07-31 02:48:24

物理層也可以根據安全需求來確定。例如DMZ中的Web服務器（帶有業務層）可能無法訪問數據庫。此外，如果您的應用程序設計正確，則可以將整個應用程序部署在單個物理服務器上（現在將數據庫留出），如果負載太高，則可以使用另一個負載平衡服務器進行擴展（但仍然是一個物理層）。 – 2009-07-31 12:58:33

如何拆分數據層和業務對象層，每個層的適當職責是什麼？

回答

相關問題