CLI缺憾之一：公共體系結構定義

Hierarchical Structure是一種應用極其廣泛的數據結構(樹結構)，其意義完全可以和Collection結構相提并論。可是.Net Framework的CLI提供了Collection卻沒有提供Hierarchy。絕大部分情況下，你可以通過其它方式(例如配合集合再定義一些接口)來實現，但是不能否認這些實現都很受局限，并且存在一些明顯不合理的依賴。我在實現業務邏輯的時候，想通過某種方式通知表現層通過Hierarchy的方式來處理。而表現層是通過一個實現Hierarchical Structure的公共控件實現的(這樣的情況在.net下非常普遍)，沒有理由要依賴我特定的業務層。

我所期望的Hierarchy服務至少應該提供兩個接口和一個基類：

• INode：節點，標定節點的標識、上級節點及子節點集合；
• INodeList：節點集合，可以認為是IList的派生接口，除完成IList的所有功能外，還必須負責與父節點的連接。
• NodeCollectionBase：節點集合基類，可以認為是CollectionBase的包裝版本，完成集合管理及父節點的標識。

之所以我覺得這個服務應該由CLI提供，很簡單的理由，這些結構應用非常普遍，完全應該是一種公共的、基本的依賴。

我設計的Hierarchy服務在Kanas.Hierarchizations命名空間，除了以上接口和基類外，還提供了一個服務類和兩個將普通類型包裝成Hierarchical結構的接口。

• Hierarchy服務類：提供了大量Hierarchy的算法，例如求寬度、求深度、求子節點數、求級別等等，另外還通過相關的包裝器接口生成Hierarchy體系的功能。
• IHierarchizer接口：提供將普通類包裝成INode的接口。
• IHierarchizable接口：提供普通類的線型集合實例及IHierarchizer接口的實現。

應用場景：菜單，可視化的樹視圖，目錄體系、組織結構、財務科目、詞典類，等等等等。

?

CLI缺憾之二：可視化框架

.Net提供的PropertyGrid是Visual Studio.net設計時支持的基礎，為此，Microsoft為.Net的PropertyGrid提供了極其強大的擴展能力。ComponentModel命名空間下的很多類型及屬性都提供了對編輯器、設計器、類型轉換器的支持。不過很顯然地，其中存在一些設計漏洞，例如沒有提供足夠的抽象，直接導致了某些不必要的局限。其后果一是所有提供設計時支持的Attribute都幾乎只能應用于PropertyGrid，讓運行時類型背負設計時支持的包袱顯然有種職責不清的嫌疑；其后果二是PropertyGrid只提供了下拉和彈出兩種模式的類型編輯，當然目前是夠用的，但不能保證任何時候都夠用。

現如今我就遇到這個問題。TypeConverterAttribute和TypeEditorAttribute這兩個屬性就必須進行Web架構的擴展而不是完全依賴WindowsForms。直觀的感覺是，設計時特征依賴運行時特征是合理的，相反則不合理。當然，設計時Attribute在運行時沒有任何意義，也不會給運行時帶來額外的性能問題。可是，為什么不能將設計時Attribute設計成更好的模型？例如可以設計成侵入式或者附加式。

我設計的對象設計時服務在Kanas.ObjectScope命名空間，采用的是附加式策略。當需要在運行時使用類似設計時服務的功能時便可以更靈活地使用。這個服務是基于一個Xml的Schema，將對象的探查或展示方案部署到相應的配置文件中，運行時根據這些配置獲得設計時支持。與ComponentModel的設計思想一樣，這一套服務應該包括公共定義(契約)、配置提供器(服務)、對象展示及編輯(消費)三部分。

定義部分包括一個XSD規范及其對應的對象模型、一個數據轉換器接口和一個編輯器接口。配置提供器包括一個配置閱讀器基類(設計成Component以備設計時使用)、三個不同配置方案的實現(分別實現對Xml配置文件、Xml配置資源和全局配置文件節三種配置方式)。對象的展示是表現層的事情，本套服務不需要實現。不過在本套服務中，通過配置的數據轉換器接口實現了從對象集合到數據集的自動轉換，分別是Kanas.Common命名空間中的TypeBoundDataTable和ListDataTable。兩者的區別是：前者不依賴Scope方案，單純實現ICollection到DataTable的轉換；后者是前者的派生，可以通過Scope方案影響DataTable的生成。

當然，這個方案也存在很大的局限，甚至顯得非常粗糙。不過就其擺脫消費依賴來說還是有意義的。當然，眼下只實現了對Property的配置，缺乏對實現對invocation及event hook的擴展，也缺乏對更詳細的可視化屬性(例如ComponentModel中的CategoryAttribute)的定義。

這就是這個簡陋的schema：

下載這個實現，如果需要源碼請來信索取。

總結

以上是生活随笔為你收集整理的细节决定成败：一个公共类库的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。