OpenExpressApp：實體擴展屬性系統 - 設計方案說明書

先說屬性擴展：我們一般會對產品中定義好的類的屬性進行以下擴展：添加一個屬性、刪除一個屬性、修改一個屬性。（所以，擴展並不只是意味着添加。）添加屬性意味着我們需要為已經定義完成的類添加一個額外的屬性，這個屬性可以映射到數據庫，可以在產品界面中顯示，行為和直接定義的屬性是一致的。刪除屬性則意味着，數據庫中不再有對應的字段，界面不再顯示。修改屬性一般只會修改屬性的各種元數據，例如，修改它映射數據庫的字段元數據，修改它在界面中顯示的列的元數據等；這些修改其實已經在元數據的設計方案中解決，相關內容可以查看：《基於OEA框架的客戶化設計（一）總體設計》、《基於OEA框架的客戶化設計（二）元數據設計》以及《基於OEA框架的客戶化設計（三） “插件式”DLL》。

實體的擴展一般可以通過繼承的方法實現，當繼承出新的子類后，在元數據中用它將原來的父類進行覆蓋即可。有些時候，我們還會為某個類擴展一些聚合父子關系，例如：我們可以為某一個建設項目擴展出其相關的合同列表，這樣，原來只顯示項目的界面中，就能緊接着顯示每一個項目相應的合同列表。而這種聚合父子關系的擴展，雖然是實體級別的添加，但是實質上是對實體添加新的一對多關系。也就是說，這種實體的擴展，可以轉換為屬性擴展，即在原有實體的基礎上擴展一個一對多關系的屬性。

基於以上分析，我們知道，一個可擴展的屬性系統，幾乎是客戶化軟件產品運行時的最基礎設施。

在 2.6 版本之前的 OEA，屬性擴展主要使用繼承的方式來實現。簡單地說，就是繼承需要擴展的實體，添加新的屬性，然后使用這個實體替換掉原來的類。該方案主要是為了實現屬性的添加，但是屬性的刪除以及修改都是通過修改屬性的元描述來實現的。這樣的方式導致了許多問題：屬性的刪除只是刪除了界面，而數據庫、運行時實體也都還存在該屬性；屬性的修改不能修改屬性中的行為代碼；重點說下屬性的添加造成的缺點：

經常需要對某個類擴展一兩個屬性，而現在只能繼承出子類，同時把父類隱藏起來，或者直接覆蓋父類，用進來比較復雜; 同時，類型變多，開發人員的學習成本，維護成本都隨之變大。

更重要的是，.NET 中 CLR 單繼承體系的限制，使得通過繼承無法實現這樣的擴展: 兩個獨立的擴展包“2”以可選的形式對主包“7”進行擴展，也就是說，產品 721 客戶化開發中，兩個“2”的擴展包是兩個單獨的程序集，但是單繼承的限制，我們不能同時使用它們。對於這種情況，我們目前的處理方式是把兩個“2”的包都放到了主包中，而使用元數據的方式對不需要的功能來進行隱藏，這種實現方式是臨時的、錯誤的。

1.2 實體動態列

軟件開發中常常遇到動態列的需求：表格中的數據的列是根據數據本身自動生成的，這對於基於領域實體類型、基於非動態類型的技術框架來開發的系統來說，要實現動態列基本上不可能。所以往往應用程序會另辟捷徑，使用 DataTable 來重新組裝數據后再顯示。這導致兩種模式同時存在於一個系統中，同樣的代碼會重復出現，增加維護成本。界面的代碼不一致，也加大了界面自動生成的困難。

如果有了擴展屬性，我們則可以在任意實體上擴展各種新的屬性，界面也就相應地成了“動態”列。

1.3 分離只讀/視圖屬性

實體設計中常常會添加一些只讀的屬性，它的值是使用實體當前的值經過計算后得出。在 OEA 中，實體被設計為分布式對象（簡單地說，就是客戶端和服務端重用一套實體代碼。可以參見CSLA框架設計書籍《Expert C# 2008 Business Objects》。），這些分布式對象被直接綁定到界面上。為了界面顯示的需要，常常會為它們添加許多只讀的視圖屬性，這樣就導致了視圖屬性過多，混雜在領域實體的代碼中，污染了代碼，加大維護難度。

如果有了擴展屬性，我們則可以把這個只讀屬性都放到一個單獨的類中去為這個實體做擴展，這樣，就可以得到更簡潔、結構更清晰的代碼。

1.4 提升框架性能

對於框架開發來說，常常需要在框架中對實體的屬性做統一的處理，來向應用層提供強大的功能支持。如果使用一般的實體設計，那么屬性值的獲取、設置都不可避免地要使用到反射。而大量的屬性值操作將會意味着較差的性能。如果有了托管屬性，則在框架層面能夠使用和應用一致的屬性 API 來操作屬性，不再使用反射，速度可以有不少提升。

1.5 支持 WPF 綁定

一般情況下，我們使用 WPF 綁定時，都是直接綁定到 CLR 托管屬性上。但是，如果使用擴展屬性的話，並不是所有屬性都會有一個 CLR 屬性封裝器。所以，這些擴展屬性必須支持 WPF 綁定也是我們的需求之一。

1.6 其它需求

l 支持屬性反擴展

在產品 721 開發中，常常在 “1” 的客戶化版本中需要刪除 “2”版本中為“7”擴展的屬性，這時，需要支持屬性的反擴展（或叫反注冊）。

l 獲取屬性值來源

由於目前 OEA 框架中的實體是分布式對象，我們常常需要在實體屬性改變時分辨屬性值的來源：是數據庫，還是UI界面，還是來自程序中的其它代碼。

l 定制序列化的數據

實體屬性被框架管理后，可以很輕易地實現各種數據格式的序列化。

l 需要支持屬性值的驗證、強制、更改通知等事件通知。

l 元數據重載

屬性的一切行為都將以回調的形式存放在元數據中。而元數據是可以被重載的。這樣，子類就才重寫這些行為。同時，我們就可以在進行產品客戶化的時候，為屬性重新定制這些行為。

最后，可以看一下在《實體擴展屬性方案分析腦圖》腦圖文檔中整理出來的需求概況圖，這些需求都是歷史版本中所不能支持的：

圖1. 實體擴展屬性需求列表

2 分析

由於前面已經把需求整理得比較明朗了。那么這里，我們首先要分析出主要需求、約束及相關的風險等。（關於框架設計的整個過程，可以參考這篇文章：《框架模塊設計經驗總結》。）

2.1 主要功能需求

其實在圖一中已經把需求按照優先級別進行了划分，后面的整個設計將會圍繞這些需求進行。其中，最主要的功能性需求是以下三個。而設計目標則是至少實現以下三個需求，其它需求則按優先級盡可能實現。

l 721客戶化開發中的屬性擴展

l 屬性托管（受框架管理）
意思是需要為上層框架提供統一維護屬性值的功能。

l 動態列

2.2 非功能需求分析

l 運行時性能

實體屬性可以說是實體設計中最重要的部分。而它的性能好壞則關系到系統中每一個實體的每一個屬性，這些屬性都直接關系到應用的性能。簡單地說，如果屬性系統慢，上層應用的性能必然會慢。換句話說，屬性系統的代碼開發是對性能十分敏感的，在核心代碼上需要十分謹慎。

2.5 版本的OEA框架使用的屬性主要還是 .NET 中的原生 CLR屬性系統 + CSLA 開源框架中的屬性系統。主要是為了支持屬性的統一管理。而本次設計，可以對系統帶來許多的新功能和支持，加之原有系統的屬性性能並沒有構成應用層開發的性能問題，所以，一定的性能消耗是可以接受的。

對這項的要求是：

使用同樣的代碼，和歷史屬性系統進行屬性測試對比，耗時不能超過原有的120%。

比較簡單，也比較嚴格。一旦不滿足此項，整個設計不可以被使用。

l 獨立性

雖然實體擴展屬性系統是作為 OEA 框架的一個重要組成部分，但是托管屬性、擴展屬性的需求在開發過程中常常會碰到。所以我們需要把實體擴展屬性系統設計為一個獨立的 DLL，這樣，它就可以在非 OEA平台的環境中使用。

l 可擴展性

EMPS的可擴展性並不是指該系統帶來的屬性的可擴展性（這其實是EMPS的功能需求），而是指屬性系統本身需要進行一些擴展。

當前，OEA框架中以產品元數據為整個框架的基礎設施。也就是說，OEA 框架中有管理應用中所有元數據的功能。而由圖1中的需求列表可以看到，EMPS也需要元數據的支持，例如屬性的默認值。但是，獨立性中已經要求EMPS被設計為一個完全獨立的模塊，也就是說EMPS完全不依賴 OEA。那么，這些屬性的元數據如何支持使用 OEA 來進行保存呢？這，同樣是EMPS 設計過程中需要特殊考慮的一個擴展點。

l 易用性

此項為框架設計必須考慮的一個非功能需求。

2.3 約束

l ORM功能的修改

原來的OEA的ORM中支持使用OEAORM及EntityFramework4.1（CodeFirst）兩種模式，但是這兩種ORM當前無疑都只支持對CLR屬性的映射。而擴展屬性是沒有CLR屬性包裝器的，但是這些擴展屬性同樣需要映射數據庫。

也就是說：如果EMPS開發完成，要映射新的擴展屬性，必須要修改當前OEAORM模塊。同時，無法再支持EntityFramework4.1了（EFCodeFirst基於CLR屬性來進行映射）。

l 原有屬性功能的兼容

2.5 版本的OEA使用的屬性主要還是 .NET 中的原生 CLR屬性系統 + CSLA 開源框架中的屬性系統。這些屬性中已經寫了非常多的代碼。屬性的 Get 獲取器及 Set 設置器中的代碼，可謂五花八門。這些都必須在新的屬性系統中被完全兼容，否則，必須導致業務功能出現問題。

l 大量歷史代碼的修改

由於本次設計本質上是一次在歷史版本上的重構，而產品開發截止到目前，已經產生了幾萬行的歷史代碼，其中的實體屬性也是幾千個。重構如此底層的設計，在盡量保證應用層 API 不變的前提下，也必然會造成較多的修改，同時，很可能會引起比較多的BUG。這是一個必須考慮的約束條件。

2.4 風險

l 屬性性能

由非功能需求的描述中知道，性能是至關重要的。關系到整個設計是否可用。但是，最終開發出來的模塊性能，在設計時很難測量的。對於這個風險的規避使用以下方案：分析歷史屬性系統的關鍵性能影響點，在設計稿完成后，理論上檢查這些關鍵點是否能在新設計出來的屬性系統下運行良好。

l 支持WPF綁定

這是一個技術難關。

當前我們只是使用了 WPF 中直接綁定CLR屬性的方案。如何能讓我們在客戶化版本的程序集中擴展的擴展屬性也支持WPF綁定，成為了一個技術上的難題。

對這點的規避很簡單，在整個設計開始之前，先分析WPF綁定中的內部機制，解決這個問題后，才能開始其它的設計。

3 設計方案

3.1 一些決策

由於本系統的設計比較復雜。所以先對兼容性約束做了一個決策：

在設計過程中盡量考慮功能上與原屬性系統保持兼容，接口上保持一致。但是當無法兼容或者無法保持一致的接口時，可以不兼容。但是這些不兼容的設計點，都需要記錄下來，當設計完成后，逐個修改。如果改動較大，則使用組內的重構工具完成。

3.2 風險點驗證

3.2.1 支持 WPF 綁定

經過查閱MSDN及搜索出的網絡資源，發現WPF中的綁定機制支持綁定DataTable數據表類型，而表中的字段則是動態的，根據結果數據的變化而變化。所以只要搞清楚DataTable是如何被WPF綁定支持的，那么EMPS也可以使用同樣的機制進行綁定。

以下是WPF中DataTable的綁定機制分析：

圖2. WPF中DataTable支持綁定的核心類型分析

圖3. WPF中為DataTable生成視圖模型的流程圖

重點在於DataTable 實現 IListSource接口，並構造動態的視圖動態類型 DataRowView並使其實現ICustomTypeDescriptor。（詳細過程參見這篇文章：《OEA 擴展屬性系統 - 任意適配 WPF Binding 的設計分析》，以及本系列中的文檔：《任意適配 WPF Binding 的設計分析》。）

搞清楚了整個設計及創建流程，那么其實在設計EMPS時，支持這個機制就可以了。

3.2.2 性能關鍵點

需要分析，歷史框架中的屬性系統（CSLA托管屬性系統）在做到托管屬性的同時，是如何保證性能的呢？

其實，它其中屬性的核心重點在於使用強類型的FieldData<T>來存儲每一個屬性，並使用定長的屬性值的數組來存放：

private IFieldData[] _fieldData;

這樣的好處在於強類型保證了沒有裝箱拆箱操作，同時定長的數組支持了以O(1)的復雜度來查找指定屬性：

但是，這樣搜索屬性的前提是屬性值數組定長，而一個實體類型到底有多少個屬性，是在編譯期已經完全確定下來的。換句話說，在這個數組初始化時必須知道固定的屬性個數，這違背了屬性可擴展的需求，這也是為什么使用這個屬性系統很難做到擴展的原因。

當然，在對其進行較大改動的前提下，也不是不可能。但是考慮到CSLA是個開源框架，其滿足需求與我們的需求有較大的區別，代碼比較臃腫，也無法實現我們所需要的一些功能，對它做大型的改動不如重新做一個完全符合需求的托管屬性框架。

經過之前的分析，可以想到，要得到較高性能的托管屬性系統，最好也是使用“強類型存儲屬性值”加“定長數組”的方案。但是如何支持屬性的擴展呢？“划分屬性定義期”是個較好的解決方案。之后的主體設計中會對這個方案進行詳細的描述。

3.3 方案描述

整個設計中，借鑒了CSLA托管屬性以及WPF依賴屬性的設計，然后再構建出我們自己的屬性系統：

3.3.1 結構說明

圖4. EMPS結構說明

腦圖比較簡單，其中的具體內容可以參考腦圖《擴展屬性方案》。這里只做簡要說明：

l 靜態結構

總體上，靜態結構比較簡單，主要分為兩個層次。底層是抽象的屬性元數據提供子系統，而另一層則是依賴於前者而構建的EMPS核心：運行時擴展屬性子系統。

提取抽象的屬性元數據提供系統是為了使元數據的存儲、提供都抽象化，后面可以和 OEA 中的元數據存儲模塊進行適配。

而核心的EMPS則實現了整個的托管屬性。后面將會對其以類圖的形式重點說明。

l 動態結構

在這里比較特殊地提出了屬性生命周期的概念。屬性的生命周期規定了屬性被定義（或者被反注冊）的時期（可能叫定義期會比較正確。），這里主要有編譯期、啟動期、運行期。

l 編譯期

此階段中定義的屬性主要包括使用代碼編寫的一般屬性、擴展屬性。當然，也包括“2”和“1”的擴展包中編寫的一些對“7”的包中實體類進行擴展的擴展屬性。

定義屬性時，一同指定它對應的元數據。

l 啟動期

此階段主要以客戶化定義的方式來對編譯期屬性及其相應的元數據進行修改。

l 運行期

該階段主要用於附加運行時動態屬性。

這些動態屬性一般只用於顯示，它們會影響界面的生成。屬性的擴展和刪除，要在生成控件之前就能確定，否則，界面沒有對應的列。

由於影響界面生成，所以需要為其指定OEA框架中對應的界面元數據。如果不指定，則使用默認元數據。不過這些元數據的設計會在OEA框架中完成，與EMPS的設計無關。

在這個階段中擴展的附加屬性，不會與服務端程序有任何關系。也就是說，不需要為這些擴展屬性定義 ORM 等服務端元數據。當然了，這些屬性的數據也不需要序列化后在網絡上進行傳輸。

划分出這幾個周期的主要原因：使得可以判斷出某個實體的編譯期、啟動期屬性列表長度。這是因為，編譯期和啟動期已經定義、修改或者客戶化的屬性，當程序進入運行時后是不會再發生改變的。而這些屬性占據了應用開發的95%以上。所以我們只要知道了編譯期啟動期屬性的長度，也就意味着可以使用O(1)檢索的數組來存放，而不是更慢的List/HashTable，保證了這些屬性的性能。而對於運行時屬性來說，雖然它的長度不能固定，根據業務場景而變化，但是使用情況較少，可以不考慮性能。

3.3.2 相關UML圖

完整的UML圖，參見：《實體擴展屬性UML設計圖》。下面將挑選重點進行說明。

圖5.擴展屬性核心類結構概要設計圖

這張是實現擴展屬性的核心類結構概要設計圖，其中主要包含 ManagedPropertyObject、ManagedProperty、ManagedPropertyField、ManagedPropertyMeta等。由於是概要設計圖，其中的方法、屬性等相對實現完成后的系統來比，肯定不完整，但是它的作用主要是說明整個設計的核心思想。其中：

ManagedProperty 表示托管屬性，每定義一個托管屬性，系統都會生成一個此類型的對象用於標記。獲取、設置屬性的值時，都需要提供此標記來進行檢索。

ManagedPropertyMeta 表示托管屬性元數據，其中提供了許多信息，例如：默認值、是否只讀、屬性變更邏輯回調等；這些元數據對屬性值的獲取、設置的邏輯都有着比較大的影響。

ManagedPropertyField 表示某個對象中某個托管屬性對應的值。其實這個類后期在實現時會被定義為泛型類，這樣，值的存儲就不是object而是強類型的，不需要裝箱拆箱操作。

ManagedPropertyObject 表示擁有托管屬性的對象基類（實體），其中定義了根據ManagedProperty來獲取、設置值的接口，這使得該對象能夠象一般對象一樣獲取、存儲各種值。同時，它也提供了統一處理所有托管屬性值的接口，此類統一處理的接口在應用開發時很少用到，主要給上層的框架使用。上層框架可以應用這些接口完成以下的框架任務：統一的對象值拷貝、統一的序列化、檢索特定類型的值等，這樣的值的獲取、設置速度，遠比反射要快。

圖6. 擴展屬性倉儲概要設計圖

這張圖說明整個系統中的托管屬性都是被系統中的單例對象 ManagedPropertyRepository 給管理起來的，為了給上層提供更方便的查詢功能，也方便存儲，它使用 TypeIndicators 類來存儲某個實體類型的屬性列表。TypeIndicators這個類也負責為上層提供查詢：某一個類型已經定義好的屬性列表、某一類型及其所有父類定義的所有屬性的聯合屬性列表。同時，這個類中的屬性都會生成在類型中的屬性的索引，這樣，在獲取屬性值時就可以使用這個索引在屬性值數組中進行屬性值的查找。

圖7.擴展屬性元數據概要設計圖

前面提到過，為了保證 EMPS的獨立性，我們需要把托管屬性元數據的數據獲取方案抽象化，這里的 IPropertyMetaProvider 就是抽象的元數據提供器接口。而上層的OEA框架則會實現自己的提供器 OEAPropertyMetaProvider，並通過自己的元數據模塊中的信息（例如圖中的OEAPropertyMeta）來為托管屬性提供元數據。

圖8. 擴展屬性實體實現WPF綁定相關概要設計圖

這張圖看上去會比較眼熟？沒錯，它和圖2中的WPF支持DataTable綁定的類圖比較相似。主要也是讓 EntityList 實現 IListSource接口，並添加 EntityView 類實現 ICustomTypeDescriptor 接口，這樣，就可以實現動態屬性的WPF綁定了。

3.3.3 如何支撐需求

主要的設計方案及類圖看完之后，我們需要考慮，整個方案是否能支撐起前面說到的所有需求。下圖是對整個需求的可支撐性進行分析。相關內容可以參見：《實體擴展屬性方案分析腦圖》,在此不再贅述。

圖9. 設計方案對需求的支持度分析。

3.4 重點實現細節

在對需求支持分析之后，再經過召開的設計評審會議，發現這樣的方案可以實現基本全部需求。這樣，就進入實現環節了。實現環節就關注更多了細節性設計。本文檔將會挑選一部分重點進行說明。

首先，先來看看最終完成的代碼中，最核心部分的代碼結構圖：

圖10. 核心代碼結構圖

整個結構的實現與設計相差無幾。接下來，說明一些相對重要的代碼：

l 先是ManagedPropertyObject中的屬性值獲取、設置相關代碼：

前面的設計方案中提到，這個類主要作為所有實體類的基類，提供值的獲取、設置等。而這個類其實是把屬性值的管理都放到了內部的一個類ManagedPropertyObjectFieldsManager 中：

並把相關的操作都代理到這個類上：

而 ManagedPropertyObjectFieldsManager則實現了這些邏輯的核心代碼。其中，它的私有字段定義如下：

可以看到，編譯期、啟動期屬性值與運行期屬性值被分開存放。前者使用數組，構造函數直接初始化，而后者則在需要時才會被序列化。還注意到，它繼承自CustomSerializationObject，使得整個屬性值列表是可以被自定義序列化的。下面，是泛型的屬性值獲取與設置邏輯：

internal TPropertyType GetProperty<TPropertyType>(ManagedProperty<TPropertyType> property)

{

var useDefault = true;

TPropertyType result = default(TPropertyType);

if (property.IsReadOnly)

{

result = (property as ManagedProperty<TPropertyType>).ProvideReadOnlyValue(this._owner);

useDefault = false;

}

else

{

if (property.LifeCycle == ManagedPropertyLifeCycle.CompileOrSetup)

{

var field = this._compiledFields[property.TypeCompiledIndex] as ManagedPropertyField<TPropertyType>;

if (field != null)

{

result = field.Value;

useDefault = false;

}

else

{

if (this._runtimeFields != null)

{

IManagedPropertyField f;

if (this._runtimeFields.TryGetValue(property, out f))

{

var field = f as ManagedPropertyField<TPropertyType>;

result = field.Value;

useDefault = false;

}

var meta = property.GetMeta(this);

if (useDefault) result = meta.DefaultValue;

result = meta.CoerceGetValue(this._owner, result);

return result;

}

internal void SetProperty<TPropertyType>(ManagedProperty<TPropertyType> property, TPropertyType value, ManagedPropertyChangedSource source)

{

ForceNotReadOnly(property);

var meta = property.GetMeta(this);

bool cancel = meta.RaisePropertyChanging(this._owner, ref value, source);

if (cancel) return;

var hasOldValue = false;

TPropertyType oldValue = default(TPropertyType);

ManagedPropertyField<TPropertyType> field = null;

//這個 if 塊中的代碼：查找或創建對應 property 的 field，同時記錄可能存在的歷史值。

if (property.LifeCycle == ManagedPropertyLifeCycle.CompileOrSetup)

{

field = this._compiledFields[property.TypeCompiledIndex] as ManagedPropertyField<TPropertyType>;

if (field == null)

{

//不管是不是默認值，都進行存儲。

//不需要檢測默認值更加快速，但是浪費了一些小的空間。

//默認值的檢測，在 GetNonDefaultPropertyValues 方法中進行實現。

field = property.CreateField();

this._compiledFields[property.TypeCompiledIndex] = field;

}

else

{

oldValue = field.Value;

hasOldValue = true;

}

else

{

if (this._runtimeFields == null)

{

this._runtimeFields = new Dictionary<IManagedProperty, IManagedPropertyField>();

}

else

{

IManagedPropertyField f;

if (this._runtimeFields.TryGetValue(property, out f))

{

field = f as ManagedPropertyField<TPropertyType>;

oldValue = field.Value;

hasOldValue = true;

}

if (field == null)

{

field = property.CreateField();

this._runtimeFields.Add(property, field);

}

field.Value = value;

if (!hasOldValue) { oldValue = meta.DefaultValue; }

if (!object.Equals(oldValue, value))

{

//發生 Meta 中的事件

var args = meta.RaisePropertyChanged(

this._owner, oldValue, value, source

);

//發生事件

this._owner.RaisePropertyChanged(args);

}

可以看到，編譯期屬性主要通過一維數組進行存放，數組中每一個元素都是強類型的泛型對象 ManagedPropertyField<TPropertyType>。

另外，要注意的是，該類提供了同樣的非泛型接口：

非泛型方法主要是為上次框架提供，其中主要考慮裝箱拆箱操作的性能消耗。（關於接口加泛型類的底層框架設計方案，參見：《重構實踐：體驗interface的威力(一)》、《重構實踐：體驗interface的威力(二)》。）

GetProperty、SetProperty 方法是對性能最敏感的兩個方法，其實現必須特別小心，其內部調用的每一個方法，如 ManagedProperty.GetMeta(ManagedPropertyObject owner)、ManagedPropertyMetadata.RaisePropertyChanged等，也都必須要做特別的優化，需要考慮到裝箱拆箱、屬性檢索、不構造多余對象等。具體代碼設計參考實際工程中的代碼，在此不做過多描述。

l 注冊屬性（及反注冊屬性）的方法位於 ManagedPropertyRepository類中。

其主要的職責是構造ManagedProperty對象，並計算它的一些重要屬性，例如：用於屬性快速Hash的GlobalIndex、用於編譯期屬性檢索值時使用的數組下標TypeIndex等。