2

我發現無論何時創建圖層/層,我都必須在一層之間進行翻譯,這是否意味着它是一個緊密耦合的系統?如果我要更改業務邏輯,刪除數據庫中的字段等,我將不得不將所有層從數據庫層更改爲客戶端前端?多層/多層系統等於緊耦合系統嗎?

E.g.一種公開「數據合約」對象的Web服務,並將其轉換爲中間層中的某些「業務對象」,然後將其轉換爲數據層中適當的「ORM對象」。客戶端調用Web服務,將數據合同轉換爲一些模型對象,等等...

既然在這兩者之間有這麼多的翻譯,那麼Web服務如何設計爲鬆散耦合呢?如果有人能夠分享他/她的觀點,那就太好了。

由於

回答

3

翻譯或映射是正交的,雖然有點相關,以鬆散耦合。

  • 如果從具體類型來具體類型映射緊密耦合
  • 如果從抽象類型到具體類型或周圍的其他方法,所述映射是鬆耦合地圖

換句話說,鬆耦合與編程到接口的概念有關,而不是映射。

如果應用程序中的圖層通過具體類型相互通信,則它是緊密耦合的。在這種情況下,分層並不能提供太多的價值,你也可能建立了一個單一的應用程序。另一方面,如果一個圖層通過接口與其他圖層進行通信,那麼這些圖層將鬆散耦合,但映射通常仍然是必需的。

+0

如果從抽象類型映射到具體類型或其他方式,映射是鬆散耦合的。 我同意從接口的角度來看它鬆散耦合,但它仍然可以緊密地耦合到數據庫表字段?例如,如果您刪除表中的列,那麼會發生什麼?你需要改變接口和映射,也就是說,耦合?多層=多翻譯並向上傳播,維護增加,所以它仍然鬆散耦合? – Joshscorp 2010-01-08 13:28:58

+0

添加或刪除數據(無論是在數據庫中,還是作爲.NET類型的成員)都將被視爲合同變更。這可能會在鬆散耦合的系統中受到更多傷害,因爲您需要在多個位置實施此更改,但另一方面,您也可以將自己與其他層中的更改隔離開來。這取決於你爲什麼介紹改變,但這不是我們通常從鬆散耦合的概念中理解的。 – 2010-01-08 13:40:00