在不同的解決方案中調用方法

目前我有一個解決方案，其層次結構如下所示。在不同的解決方案中調用方法

-GUI 
-ENTITIES 
-DATA 
-BLL 
    -ENTITIES 
    -DATA 
    -ENTITIES

1）這是正確的方式來擺脫它。我正在從GUI中刪除數據引用（只是遺留代碼，我正在移動到BLL）

2）有沒有任何方法可以從BLL或DATA調用方法？像在Entities.Order有Order.GetNextOrderID（）從DATA調用一個方法？

2014-05-12 Phalanx

佈局解決方案沒有「正確方法」。只有這個項目纔有意義。它是你的項目..所以你需要理解佈局。至於你的第二個問題 - 很難說沒有看到你的依賴關係的適當圖表。 –

http://i.imgur.com/Xx9Fquj.png多數民衆贊成我從查看項目依賴項。 – Phalanx

1）這是正確的方式來擺脫它。我目前除去GUI的DATA 參考（即我移動到 BLL只是傳統代碼）

這是一個擴展的主題，它是場景相關的。

對組件化，與其他系統和協議集成，本地代碼，多客戶端協議，移動，測試等進行圖片化。將會需要很多層和多種解決方案。同樣的原則適用於不同的平臺。

有很多標準你不得不考慮，所以答案是：這取決於。

但我想你做的事情很合適。

2）有沒有辦法讓實體從BLL或 DATA中調用方法？像在Entities.Order有Order.GetNextOrderID（），從DATA調用方法？

不，您將得到循環依賴性錯誤。單個模塊會做到這一點，但我不會推薦它。另外，如果您要在實體中定義驗證，請確保您的設計不會允許在服務（bll）或數據中進行重複。如果你沒有一個好的團隊或配對修正版，這可能會失控。

這些圖層的主要目的是給它特定的響應。如果你對圖層有明確的責任，你應該沒問題。

2014-05-12 04:56:40 BonanzaOne

好，一個好的設計是保持數據層獨立於GUI和BLL。因此，每個圖層都可以執行單個任務，即GUI應該只關注用戶界面，控件和視圖。業務邏輯層應該只實現業務規則，數據層應該與數據庫交互。對於第二個問題，您只需將數據項目的引用添加到實體項目。希望它可以幫助你。

2014-05-12 04:08:35 shashwat12

當我嘗試添加它時，無法添加對「數據」的引用。添加這個項目作爲參考會導致循環依賴。我明白錯誤的含義，但是如果我從數據中刪除實體，那我就不能保存這些實體。 – Phalanx

然後問題是你可能已經添加了'實體'到'數據'的引用。哪一個是錯誤的，如果你需要他們互相交流而不是把他們放在同一個項目中。分層是以單向的方式完成的。上層可以訪問下層，反之亦然。 – shashwat12

我再次重申我的意見，問題1

是不是正確的方式打下了出來。

「正確的方式」是項目的依賴。

有沒有任何方法可以讓ENTITIES從BLL或DATA調用一個方法？像在Entities.Order有Order.GetNextOrderID（）從DATA調用一個方法？

不符合你當前的設置..你會得到一個循環依賴。你已經在更多的DDD方法（這是你要去的地方......很好！）和一個邏輯位於實體之外的貧血域模型之間混淆起來。

您應該選擇大部分邏輯的座標和工作位置。對於您所詢問的DDD方法，Entities項目將包含您的邏輯的90％，並且它將依賴於實體可能需要的任何其他「服務」的「BLL」項目。

貧血領域模型的缺點在於，您在BLL中有一項服務來加載它所需的一切，並在實際服務中執行所有操作。你的實體只不過是POCO。

2014-05-12 04:15:00

所以真的要「解決」這個問題，我應該合併？如果我繼續使用DDD方法，大部分實體和數據層？ – Phalanx

不要合併實體和數據層。實體堅持無知。你的用戶界面可以有一個「服務」層，它用來與數據庫交互..但是一旦它有這些實體，它應該推遲所有的邏輯。然後爲其他任何非實體特定的邏輯創建另一個「BLL」程序集。 –

回答