、、，這三者之間的關系;二是沒有理解.NET中各個對象的本質含義，比如這裡的特性(Attribute)，大部分人都認為它是被用來作為代碼說明、標識使用的，而沒有突破這個思維限制，所以在設計一些東西的時候會繞很多彎路；還有一點是很多人對C#中的語法特性分不清版本，當然我們要大概的了解一下哪些特性或者語法是C#2的哪些是C#3的，這樣在我們設計東西的時候不會由於項目的版本問題而導致你無法使用設計技巧，比如擴展方法就無法使用在低於.NET3.0版本中，LINQ也無法在低於.NET3.O的版本中使用；
.NETFramework的版本不斷的在升級，目前差不多5.0都快面世了；.NETFramework的升級跟C#的升級沒有必然的關系，這個要搞清楚；C#是為了更好的與.NET平台交互，它提供給我們的都是語法糖，最後都是.NETCTS中的類型；就比如大家都在寫著LINQ，其實到最後LINQ也就被自動解析成對方法的直接調用；
的方式使用，再到現在的C#3那就更方便了，直接使用面向函數式的Lambda表達式；那麼這樣還需要反射調用對象的方法嗎？（當然特殊場合我們這裡不考慮，只考慮常用的場景；）當然反射不是不好，只是反射需要考慮很多性能優化方面的東西，增加了代碼的復雜性，也讓框架變的很重（現在都是在追求輕量級，只有在DomainModel中需要將平面化的數據抽象；），所以何不使用簡單方便的委托調用呢；
注：如果你是初學者，這裡的委托可以理解成是我們平時常用的Lambda表達式，也可以將它與Expression<T>結合起來使用，Expression<T>是委托在運行時的數據結構，而非代碼執行路徑；（興趣的朋友
中，現在有一個需求就是在Infrastructure Layer 加入一個動態計算Order中指定Item.ItemUsingType的所有Prices的功能，其實也就是說需要將我們的一些關鍵數據通過這個功能發送給遠程的Service之類的；這個功能是屬於Infrastructure中的Common部分也就是說它是完全獨立與項目的，在任何地方都可以通過它將DomainModel中的某些領域數據發送出去，那麼這樣的需求也算是合情合理，這裡我是為了演示所以只在Order中加了一個SumPrices的方法，可能還會存在其他一些DomainModel對象，然後這些對象都有一些關鍵的業務數據需要在通過Infrastructure的時候將它們發送出去，比如發送給配送部門的Service Interface；
在第二個單元測試方法裡面我們將使用Lambda方式將邏輯直接注入進BusinessService中，好就好這裡；可以將Lambda封進Expression<T>然後直接存儲在Cache中或者配置中間，徹底告別反射調用吧，就好比委托一樣沒有人會在使用委托在定義個沒用的方法；(所以函數式編程越來越討人喜歡了，可以關注一下F#；)總之使用泛型解決類型不確定問題，使用Lambda解決代碼邏輯注入；大膽的嘗試吧，將聲明與實現徹底分離；
(對.NET單元測試有興趣的朋友後面一篇文章會詳細的講解一下如何做單元測試，包括Mock框架的使用；)
，就是可以在運行時讀取這個特性用來做類型的附加屬性用的；通常在一些框架中對DomainModel中的Entity進行邏輯上的關聯用的，比如我們比較熟悉的ORM，都會在Entity的上面加上一個類似
提供了好的技術實現；
【需求簡述】：對象本身的行為不是固定不變的，尤其我們現在設計對象的時候會將對象在全局情況下的所有行為都定義在對象內部，比如我們正常人，在不同的角色中才具有不同的行為，我們只有在公司才具有“打開服務器”的行為，只有在家裡才可以“親吻”自己的老婆的行為；難道我們在設計User類的時候都將這些定義在對象內部嗎？顯然不符合邏輯，更不符合面向對象設計思想，當然我們目前基本上都是這麼做的；
（有興趣的朋友可以參考：BDD（行為驅動設計）、DCI（數據、上下文、交互）設計思想；）
聲明式設計和元編程運用在C#中，比較經典就是ASP.NET後台代碼和前台的模板代碼，在運行時然後再通過動態編譯合起來，我們不要忘記可以使用部分類、部分方法來達到在運行時鏈接編譯時代碼和運行時代碼，類似動態調用的效果；
：http://files.cnblogs.com/wangiqngpei557/ConsoleApplication1.zip
