.NET 框架設計(理解)c#、.NET Library 整理(二)

1、擴展方法:

     擴展方法是讓我們在不改變原有代碼的情況下動態的添加方法的方式,這給面向對象設計、模塊設計帶來了質的提升。

      以往想要在一個類中添加某個方法,需要特別小心,尤其在設計動態下發DLL的時候。在這裏,我們完全可以將擴展方法添加獨立於一個乾淨的DLL中,與具體的被擴展類區分開,這樣就減少問題的出現。

      擴展方法可以使我們進行鏈接式編程。擴展方法是可以動態擴展某個類型,關鍵是任何類型,包括接口。試想一下,如果我們將擴展方法與對象的繼承鏈綁定起來的話,會產生什麼樣的奇妙效果?

2、部分類、部分方法

       部分類和部分方法是編譯時的動態合併功能,並非運行時的,時C#與編譯器爲了幫助我們進行局部獨立變化而用的。他可以將類的定義分開在一個或多個類文件中,這爲代碼自動生成提供了良好的環境。自動生成的代碼時重複性的工作,而手動編寫的都是核心的業務邏輯。比如一個領域實體,其大部分字段都與持久化設備有直接的映射關係,而行爲方法卻是和具體的業務邏輯相關的,所以前者時相對固定的,而後者時需要經大腦思考才能得出的,無法自動生成。但是,這兩者都是屬於某個領域實體的不同部分,一個是數據,一個是邏輯,它們都屬於對象的必要元素,所以到最後都需要合成一個完整的對象。

        部分類、部分方法爲框架的開發提供了對外擴展這樣一個強大的功能,我們可以將部分代碼通過插件的方式自動生成,而部分方法我們只保留抽象定義部分,就好像設計模式中的模板方法模式。最後將業務邏輯和自動生成的代碼完美結合。

         靈活運行這兩個特性會使框架的設計更加深入,自動完成的工作也會大大增加,像一些服務契約、調用接口其實都是可以結合不分類和部分方法進行設計。

2、特性、元數據

        特性可以理解爲附加在類型上的一段數據屬性,可以稱爲類型的元數據。強大的是這些元數據可以在運行時動態獲取,這就爲我們在運行時動態辨別一些邏輯架起了橋樑的作用。特性可以說時框架設計中必須要使用的一個技術點,因爲他是契約式設計和AOP設計的基礎。他幫我們將複雜的業務邏輯和基礎設施分隔開來,而在運行時又動態結合在一起。

     public enum TransferSourceType // 轉賬類型

           { salary,reimburse,loan}

[AttributeUsage(AttributeTargets.Paramer)]

public class TransferSource:Attribute    // 轉賬元數據

{ publicTransfer Source TypeTransfer Type{get;set}};

public partial class Employee   // 員工實體

{

     public void TransferToEmployee([TransferSource(TransferType =TransferSourceType.Salyry)] int ToNumber)

        {}

}

=======================

參數元數據通常用來作爲上游對下游的約定,也就是說用來獲取參數特性的功能點時在方法的調用端,然後根據該方法所用的參數元數據來約定該參數。比如這裏我們使用類似轉賬的特性元數據,上游HR控制端可以控制傳入到這個方法的數據只能時跟員工工資、報銷、借款等員工應得的錢相關的,不會發送除此之外的其他數據過來,而且前後順序還不能搞錯。

3、反射、代碼對象模型、動態編譯、動態緩存

     反射時在運行時動態獲取.NET類型元數據的功能。

       一個開發時的OO對象經過編譯變成本地代碼時,就不會再存在所謂的面向對象概念,而是一堆只對計算機本身運行有用的指令。那麼我們在運行時如何繼續使用在開發時通用的OO概念,這就是反射的意義。

     在運行時,.NET會將我們定義的每一個類型保存一份元數據表,這就是我們要在運行時動態獲取一個類型的元數據的基礎元數據字典。而這個字典時字符級別的定義,也就是說動態反射獲取類型元數據時會進行字符級別的查找匹配。字符的模式匹配時非常消耗資源的,這就是我們時常所說的反射將會影響性能的地方。

      那麼我們在使用這個強大的功能時如何避開這個性能損耗點呢?比較經典的解決方法是在運行時動態生成代碼,然後再進行動態編譯,最後再動態緩存起來。這是一貫的解決思路,但是具體要控制到什麼力度,還需要客觀的衡量業務背景。

      我們剛纔提到的動態生成代碼,那麼這就將使用到.NET 的CodeDom模塊,這個模塊是.NET提供給開發人員用來動態的生成代碼用的,而他的一套對象模型對應着代碼的結構,所以說這也是CodeDom的由來之因。

      對DOM有了解的朋友應該很容易理解這個概念:DOM文檔對象模型的意思是通過文檔來保存對象的結構,也就是說是對象的文檔持久化。我們只要能明白,文檔的結構與對象的結構從某種角度看是一致的,而且很容易將其序列化和反序列化。

     通過.NET提供的一套CodeDom模塊生成代碼之後,就可以通過.NET提供的動態編譯模塊將一組代碼字符串動態的編譯成可以直接運行的內存對象,這樣我們就可以將原本需要很多反射步驟才能完成的事情通過直接調用的方式完成,這將大大提高程序的性能。

      最後將動態生成的對象緩存起來,在下一次需要的時候再直接讀取出來使用。這就保證反射對性能的消耗只在第一次,而後續的同樣的功能將等同於類級別的直接調用。

 

 

 

 

 

 

    

 

 

 

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