要說得很清楚，我不期望解決這個問題。解決這個問題的很大一部分顯然是解決問題。但是，我沒有很多體系結構良好的n層應用程序的經驗，並且我不想結束一個不守規矩的BLL。如何設計一個業務邏輯層
在寫這篇文章的時候，我們的業務邏輯主要是一個混雜的麻線球。一系列相互依賴的星系間業務邏輯不止一次被複制。我現在的重點是將業務邏輯從我們稱之爲數據訪問層的事物中拉出來，以便我可以定義可以訂閱的衆所周知的事件。我想我想支持事件驅動/響應式編程模型。
我的希望是有一定的可實現的目標，告訴我如何以適合業務邏輯的方式設計這些類的集合。如果有一些區分BLL和BLL差的事情，我想多瞭解一些BLL。
作爲一個經驗豐富的程序員，但相當謙虛的建築師，我問我的同胞社區成員的建議。
所以驗證邏輯進入業務對象，但是這意味着，該業務對象需要溝通驗證錯誤/邏輯回到GUI。這讓我想到將業務操作作爲對象而不是對象來實現，以提供關於操作必要性的更多元數據。我不是代碼克隆的忠實粉絲。
一種廣泛的問題。用ORM技術（NHibernate或許？）將你的數據庫從業務邏輯（可怕的術語）中分離出來。這讓你在大多數情況下（顯然）都停留在OO領域，並且從建築的角度來看，你大都可以忽略事物的DB方面。
接下來，我發現領域驅動設計（DDD）是將複雜系統分解爲可管理塊的最成功方法，雖然沒有得到尊重，但我真正發現UML - 特別是動作和類圖 - 是關鍵的有助於理解和溝通系統設計。
一般建議：接口一切，從一開始就構建單元測試，並學會識別和分離可作爲子系統存在的可重用服務組件。 FWIW是否有一羣你在這個工作我也同意並積極使用stylecop從得到去:)
確實是一個很寬泛的問題，但是，BLL真的是這個未定義的東西嗎？ – 2010-11-03 10:43:31
更多的是它有大量的定義。這就像試圖問某人什麼是合適的車。 – annakata 2010-11-03 11:45:11
但是必須有更多。我明白，「這取決於」，但我們追求解耦和層體系結構有一個原因，我只是想弄清楚爲什麼以及BLL是如何理解的。 – 2010-11-03 13:02:48
看看這個話題。可以給你一些想法。
How should my business logic interact with my data layer?
這guide from Microsoft也可能是有幫助的。
嗯，我可以告訴你我們用於一個相當大的數據庫爲中心的應用程序的技術。我們有一個類來管理數據層，正如你所建議的那樣，後綴爲DL。我們有一個自動生成這個源文件的程序（這非常方便），儘管它也意味着如果我們想擴展功能，你需要派生類，因爲在重新生成源代碼時你會覆蓋它。
我們有另一個文件結束OBJ，它簡單地定義了數據層處理的實際數據庫行。
最後但並非最不重要的是，如果一個格式良好的基類有一個以BS（代表業務邏輯）結尾的文件作爲唯一沒有自動定義事件方法的文件，例如「New」和「Save」等通過調用基地，默認行動已完成。因此，任何偏離標準的情況都可以在這個文件中處理（如果需要，可以完全重寫默認功能）。
您應該爲每個表及其從該主表派生的子表（或子孫表）創建一組這樣的文件。您還需要一個工廠，其中包含所有對象的全名，以便可以通過反射創建任何對象。因此，爲了修補程序，您只需從基本功能派生並更新數據庫中的一行，以便工廠創建該對象而不是默認值。
希望有所幫助，儘管我會離開這個社區wiki響應，所以也許您可以對此建議獲得更多反饋。
我發現域驅動設計的一些實踐在將複雜的業務邏輯分解爲更多可管理/可測試的塊時非常出色。
有從以下鏈接通過示例代碼一看：你的域層或BLL上
DDD的重點，如果你喜歡，我希望它能幫助。
我們只是從架構的角度來談論這個問題，它的主旨仍然是「抽象，抽象，抽象」。
您可以使用EBC自上而下設計並將接口定義傳遞給程序員團隊。使用這樣的方法（或任何其他可視化技術）可視化依賴關係可以防止您在項目中的任何位置複製業務邏輯。
這很有趣，我不瞭解EBC。絕對值得探索。我不確定它可以直接適用多少，我可以從中學習。謝謝。 – 2010-11-03 10:42:06
關於「編輯1」 - 我已經遇到了這個問題很多次。我完全同意你的看法：有多個地方必須進行相同的驗證。
我過去解決它的方式是以某種方式封裝驗證規則。元數據/ XML，單獨的對象，無論如何。只要確保它是可以從業務對象請求的東西，在其他地方執行並在那裏執行。這樣，您只需編寫一次驗證代碼，並且可以由您的業務對象或UI對象執行，甚至可以由您的代碼的第三方使用者執行。
有一個警告：一些驗證規則很容易封裝/運輸;例如，「姓氏是必填字段」。但是，您的一些驗證規則可能過於複雜，涉及太多對象，無法在元數據中輕鬆封裝或描述：「僅當用戶不是員工時，用戶纔可以包含該優惠券，並且該訂單放置在勞動節週末，除非他們在購物車中還有其他物品，否則他們的購物車中有2至5件這種特殊類型的物品，但是隻有當這種顏色是我們的'首選銷售'顏色之一，除了等等等等。 「 - 你知道生意如何」邏輯「！ ;）
在這些情況下，我通常只接受這樣一個事實，即只會在業務層完成一些額外的驗證，並確保在發生這些錯誤時可以將這些錯誤傳播回UI層無論如何，您仍然需要該通信通道，無論如何都要報告持久層錯誤）。
那麼在我的回答中，會生成代碼，但這並非嚴格要求。只是很多邏輯是重複的，雖然以這種方式組織的優點是知道代碼更改進入BS文件（或者如果出現錯誤，則更改爲每個DL）。 – Neil 2010-11-03 10:15:12
驗證邏輯隨處可見* imho。 – annakata 2010-11-03 10:15:36
您可以使用業務層中定義的專用異常類，與UI溝通有關任何驗證錯誤的信息。 – Andres 2010-11-03 10:25:18