《OEA - 实体扩展属性系统 - 设计方案说明书》
? ? 這篇設計文檔是 12 月份寫來參加公司的研發峰會的，自己倒是信心滿滿，不過最后還是沒有入圍。現在想想也沒啥大用，所以貼出來，期待與園友交流。
??? 文檔有點長，沒全部貼在博客中，有興趣的可以下載附件中的 PDF。
?附件：《實體擴展屬性系統-系統設計說明書.pdf》
================= 分隔線 ======================
?
?
目錄
前言... 4
1 背景與需求... 5
1.1 產品 721 客戶化開發的需要... 5
1.2 實體動態列... 6
1.3 分離只讀/視圖屬性... 6
1.4 提升框架性能... 6
1.5 支持 WPF 綁定... 6
1.6 其它需求... 7
2 分析... 8
2.1 主要功能需求... 8
2.2 非功能需求分析... 8
2.3 約束... 9
2.4 風險... 9
3 設計方案... 10
3.1 一些決策... 10
3.2 風險點驗證... 10
3.2.1 支持 WPF 綁定... 10
3.2.2 性能關鍵點... 12
3.3 方案描述... 12
3.3.1 結構說明... 13
3.3.2 相關UML圖... 14
3.3.3 如何支撐需求... 18
3.4 重點實現細節... 18
4 設計驗證... 24
4.1 功能需求驗證... 24
4.2 WPF綁定驗證... 24
4.3 性能驗證... 25
5 使用手冊... 25
5.1 使用場景介紹（單元測試）... 25
5.1.1 屬性默認值... 26
5.1.2 強制替換屬性值... 27
5.1.3 屬性值設置時的取消與強制替換... 27
5.1.4 引用實體屬性的設置取消... 28
5.1.5 屬性變更事件... 29
5.1.6 產品721擴展屬性... 30
5.1.7 所有擴展屬性的界面生成... 31
5.1.8 只讀屬性的使用方法... 31
5.1.9 只讀擴展屬性的使用方法... 32
5.1.10 運行時動態屬性（動態列）... 33
5.1.11 序列化... 34
5.1.12 WPF綁定驗證... 35
5.1.13 擴展屬性ORM驗證... 35
5.1.14 實體狀態的相關屬性... 35
5.2 代碼生成 – CodeSnippets. 36
5.3 其它問題... 37
5.3.1 擴展屬性的CLR屬性編寫注意點... 37
5.3.2 何時使用屬性擴展，何時使用繼承擴展？... 38
前言
在產品線開發中，支持產品的客戶化在產品規模化開發中是非常重要的一部分。而客戶化中的非常重要的一部分則是屬性值的客戶化，包括屬性值的添加、刪除、修改及屬性對應的界面的客戶化。由于產品對屬性值的擴展方案一直是使用類繼承的方案來完成，導致了產品出現了許多的問題：
l 其中最重要一個問題是有時候無法給一個客戶兩個可選的的功能包，而為了解決這個問題，開發人員又不得不做大量的代碼移植，把可選包的代碼都移植到主干版本中，導致了臨時代碼過多，維護成本太大。
l 另外，我們的產品基于實體開發，為實現動態列的需求繞了許多路，最終決定使用數據表的模式來編寫，同樣造成大量重復代碼，開發人員開發效率低下。
基于歷史遺留的這些問題，我們設計了全新的屬性系統。本系統設計完成之后，解決了許多歷史遺留問題，也帶來了許多意想不到的價值。例如：
l 支持簡單地完成客戶化開發中屬性的擴展。
l 支持更簡單地實現領域實體的動態屬性（界面中的動態列，原來要100行代碼，現在只要20行。）
l 視圖屬性分離（更好的可維護性）
l 屬性性能提升（性能提升）
l 減少了序列化數據（傳輸效率提升，性能提升）
l 統一的屬性接口（平臺可提供更加強大的功能支持）
本次設計是在歷史代碼上進行重構，但是本質上是設計一個完全獨立功能的子系統。本文從需求、分析、方案、實現、驗證等角度說明了整個設計是如何完成的。并在最后，給出了系統的使用手冊以幫助開發人員日常應用。
備注：
本文檔中，為了方便起見，將會把“實體擴展屬性系統”簡稱為 EMPS。（Entity Managed Property System，意為實體托管屬性系統）
另外，文中說到的版本號：歷史的OEA版本是2.5，升級到EMPS之后，OEA版本是2.6。
1 背景與需求
本節主要說明整個系統設計之初，設計的背景及最終整理出來的需求列表。這些需求是前期不斷收集、累積的結果。接下來，將會詳細說明一些主要的需求：
1.1 產品 721 客戶化開發的需要
部門的幾個產品都是基于 OEA 平臺開發的。OEA 平臺主要解決產品開發模式下客戶化開發、以及在產品開發過程中如何提高開發效率兩大問題。
（關于產品開發中的721概念及OEA中的客戶化設計，參見：《基于OEA框架的客戶化設計（三） “插件式”DLL》。關于 OEA 的了解，參見：《OEA 框架演示 - 快過原型的產品開發》。）
客戶化開發中，主要解決的問題是如何在客戶化版本中對主干版本中的產品進行擴展。各種擴展一般都依托于底層的元數據，這些元數據描述整個系統。當我們對元數據進行修改時，整個應用程序也就發生了相應的變化。這些產品的擴展可以簡單分為：模塊級別的擴展、實體級別的擴展、屬性級別的擴展。模塊的擴展在此不進行討論。
先說屬性擴展：我們一般會對產品中定義好的類的屬性進行以下擴展：添加一個屬性、刪除一個屬性、修改一個屬性。（所以，擴展并不只是意味著添加。）添加屬性意味著我們需要為已經定義完成的類添加一個額外的屬性，這個屬性可以映射到數據庫，可以在產品界面中顯示，行為和直接定義的屬性是一致的。刪除屬性則意味著，數據庫中不再有對應的字段，界面不再顯示。修改屬性一般只會修改屬性的各種元數據，例如，修改它映射數據庫的字段元數據，修改它在界面中顯示的列的元數據等；這些修改其實已經在元數據的設計方案中解決，相關內容可以查看：《基于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等。
4 設計驗證
4.1 功能需求驗證
已經為EMPS添加了豐富的單元測試，該項驗證的內容被整合到第5項中，參見：《5.使用手冊》。
4.2 WPF綁定驗證
驗證這個比較簡單，只要基于它的應用程序運行起來之后，界面上的值都能正常獲取、設置即可。
不過，我們還是為它加了相應的單元測試，這個在后面會有描述。
4.3 性能驗證
之前說到如果EMPS相比原來的屬性系統，如果耗時超過120%，則該系統不可用。按照之前關鍵性能點的設計，應該是可以達到，但是，還是需要做出相應的驗證工作及最終的數據。
具體內容可以參見：《實體擴展屬性系統性能測試報告》。這里說明一下最終結論：
“
性能結論：
新的 OEA 托管屬性系統，在帶來眾多新功能的同時，不但沒有降低原有性能，反而因為優化掉無用的代碼，使得速度提升。故可以放心使用該屬性系統。
”
5 使用手冊
5.1 使用場景介紹（單元測試）
由于已經為EMPS添加了比較豐富的單元測試，所以本使用手冊將主要以介紹單元測試的形式，覆蓋所有可能的使用場景，并介紹每一個場景其對應的使用方法。
單元測試所使用的實體類包含下圖中的這些類：
右圖是所涉及到的所有單元測試。
“……………………內容較多，省略，有興趣的可以看附件中的文檔………………”
5.2 代碼生成 – CodeSnippets
在《OEA 框架演示 - 快過原型的產品開發》中可以看到，OEA框架的快速開發能力中，編譯期的代碼生成技術是一個重要部分。我們同樣為EMPS的80%使用場景都編寫了CodeSnippets（關于CodeSnippets的使用方法，參見：《善用VS中的Code Snippet來提高開發效率》）：
導入VS后，只要輸入OEAP……，VS就支持這些代碼片段的生成，如：
5.3 其它問題
5.3.1 擴展屬性的CLR屬性編寫注意點
使用EMPS定義的屬性，如果不是擴展屬性，都會定義一個對應的CLR屬性包裝器，如：
注意，CLR屬性內，不能添加任何代碼，所有需要對Code屬性的Get、Set的定制代碼，都需要以回調的形式編寫在EMPS中，如：
原因是界面框架、ORM框架、WPF綁定等框架內容都不會調用CLR屬性，而是直接調用GetProperty、SetProperty方法，而CLR中的代碼只是為了方便類庫的使用。
5.3.2 何時使用屬性擴展，何時使用繼承擴展？
EMPS雖然可以直接對某個實體類型進行屬性的擴展，但是我們依然老的方案，即使用CLR類繼承機制擴展舊的實體。那么，我們需要特別注意兩種方案的區別：
1. 屬性擴展是直接對指定的領域實體進行擴展，一旦擴展，該領域實體類在整個應用程序中的屬性都被擴展。
2. 而繼承擴展則需要用于不同的領域實體中。
簡單地說，當你想在應用程序中擴展出一個新的領域實體類或者做一個全新的界面時，則使用繼承擴展。而當在做客戶化時，希望對現有的領域實體類進行完全擴展時，則應該使用EMPS來進行屬性擴展。
?
總結
以上是生活随笔為你收集整理的《OEA - 实体扩展属性系统 - 设计方案说明书》的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 功能：人脉（People Hub）7-固
- 下一篇： 分布式系统和元数据