N層架構設計關注點分離

Question

我意識到在n層設計中已經有了很多帖子，這可能是我思考問題並圍繞圈子進行的，但是我現在都會感到困惑，並且會希望從社區中獲得一些清晰的信息。

我想我創建了一個項目分開，（並沒有設計架構非常好下手），出到不同的層（各自在自己的項目）：

• UI
• 業務對象
• 邏輯/業務
• DAL

的UI只調用邏輯層來獲得它的東西

的的Business Objects不應調用或者有別的引用，只是存儲數據的方式

的邏輯/BUSINESS層應該包含所有的方法來獲取，創建，更新，刪除（CRUD）系統中的對象，並且同時引用BO和DAL。它會將業務邏輯應用於操作，然後將實際的CRUD委託給DAL。

DAL只會對數據庫執行CRUD操作。它會提及BO，因爲它會將它們返回給Gets等。

我的問題是邏輯類應該只調用它們的等效DAL類，而不是調用邏輯類？換句話說，CompanyLogic班只應該撥打CompanyDAL班。因此，如果它想通過ID獲取A Client對象，它將調用ClientLogic.GetClientByID(int)而不是ClientDAL.GetClientByID(int)。

我想這也許應該留在自己的層上的原因是：

1. 這似乎放鬆

2. 怎麼樣的邏輯項目之間的耦合，如果得到一個客戶端對象在其中有一些邏輯驗證（可能不是最好的例子，但希望它能得到）。

編輯：

我不知道，如果它是壞的設計由我，但此刻的業務層有很多類，包括ClientBULL和CompnayBULL，這兩個類有一個呼叫另一個。我爲每個類使用一個接口，並且有一個工廠來構建對象以嘗試並減少任何耦合，但現在由於在這兩個類中都調用方法，它們不能彼此存在。這是一個壞主意嗎？

Answer 1

嗯，這裏是你的設計我的意見：

• 邏輯是什麼本質上是分配給抽象持久層的壞名聲。我可能會稱之爲「Repository」或「Persistence」或DAO（數據訪問對象）而不是「Logic」，這是模棱兩可的，絕對意味着。

• 如果您確實想將您的業務層與DAL分離，那麼您的邏輯層應僅接受DAL接口，而不接受具體的DAL類。

• 關於驗證應該駐留在哪裏，有兩種思路。在UI層進行驗證時，有些是完全正確的;其他人則寧願拋出異常或傳遞來自業務層的消息。無論你走到哪裏，只要保持一致，不要在多個地方重複驗證，你就會好起來的。

• 繼續嘗試編碼吧可能是我可以給你的最好建議。很好，很好的思考它，但有一點你需要在編碼時看到它，只有這樣纔會有微妙的怪癖和陷阱。無論你想出什麼樣的原型，對於你的開發和設計帶給你的方向肯定都是有價值的。

Goodluck！

更新

回覆您的編輯：在同一個命名空間或組裝，調用具體類是絕對的罰款。我認爲你需要爲商業邏輯搭建接口會過於複雜 - 我的意思是你應該遵循不止一套規則？

我是一個讓事情變得簡單和遵循YAGNI的人。直到有兩個以上的類將實現/已經實現該接口時，才能創建接口（但DAL始終是一個例外）。