依賴和分層 -依賴

依賴(dependency):指兩個不同的實體間的一種聯繫。

例:A程序集依賴B程序集。則稱A是B的客戶(client),B是A的服務(service)

引用(Reference):引用程序集建立依賴關係。

依賴管理:

     1、實現與接口:接口的所有客戶端都不應該知道接口的具體實現方法。

     2、new代碼味道(code smell)接口描述能做什麼,接口的實現類描述如何做,只有類才能涉及接口實現的具體細節。(代碼味道:如果某段代碼可能存在問題,就可以說有代碼味道。使用new關鍵字創建對象實例屬於“狎暱關係(兩個類之間的關係過於親密,即關聯到一起)”,因爲構造函數屬於實現細節,客戶端調用構造函數可能引入意外的依賴關係(引入隱藏的程序集))

     3、缺乏可測試性:可測試性需要代碼以一定的模式構建。如果不這樣做,測試將變得極其困難。(即無法使用不執行任何動作的模擬實現來替代這兩個類的實現)

     4、更多的狎暱關係:在A類中實現了B類。如果調用B類中的方法時,B類方法中創建了C類,則A類與C類存在狎暱關係,導致出現更多的狎暱關係。

 

對象構造的替代方法:

    1、針對接口編碼:將B類中的功能提取出一個接口,A類只依賴B類中的接口而不是B類的具體實現。

    2、使用依賴注入(Dependency Injection):修改A類的構造函數,構造函數傳入B類的接口而不是B類創建的對象。這樣管理依賴的能力會提高很多。(需要客戶端代碼提供一個B類的接口的實現,將A類與B類完全解耦)

 

隨從反模式(entourage anti-Pattern):

        需要一個程序集中的一個功能,但是會引入這個程序集中很多其他不需要的東西。所以接口和接口的依賴項不應該佈置在同一個程序集內。

 

階梯模式:

       階梯模式是一種正確組織類和接口的方法。因爲接口和接口的實現類佈置在不同的程序集內,二者可以獨立更改,客戶端代碼始終只需要引用接口所在的程序集。

        好處:接口沒有任何依賴。調用接口的客戶端代碼也不會有任何的隱藏依賴,接口的實現也同樣只依賴其他僅包含接口的程序集。接口的方法和屬性不應當暴露出任何第三方引用中定義的數據對象或類。

 

依賴解析:

       程序集:公共語言運行時(Common Language Runtime CLR)使用即時(just-in-time JIT)模式來解析程序集。只有首次使用程序集中的某個特性時纔會解析應用中包含的引用。
        服務:與程序集相比,客戶端和服務之間的耦合關係更加鬆散。

                 1、已知端點:如果客戶端代碼編譯時就知道服務位置,可以爲客戶端創建一個服務代理。兩種創建代理的方式:1、VS自帶的爲項目添加服務引用。優點:節省實現。缺點:缺乏代碼控制。2、使用ChannelFactory類編碼創建服務代理。(最好用於客戶端代碼能夠方位服務接口並且可以通過引用重複使用時)

                  2、服務發現:兩種方式 託管的和自組網的。

                  3、Rest化服務(REpresentational State Transfer 表述性狀態轉移):客戶端幾乎沒有任何依賴,只需要一個所有語言的框架和庫都體用Http client實例。適合開發需要跨平臺的功能強大的服務。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章