以上幾個子產品分開是為了适應更多的項目需要，如可能用到WCF子產品，那麼實體類需要獨立引用。但是如果是純粹的Winform子產品，以最少化項目為管理原則，那麼就不需要那麼多工程了，這樣也友善項目的內建引用。雖然我們把基于多資料庫支援的邏輯及資料庫通路實作，封裝到一個WHC.StaffData.Core項目裡面，但是如果是Winform的項目應用，我們隻需要引用他的代碼路徑就可以了，這樣就保證了一份代碼實體，多次外部應用的良好處理。如下所示。
這樣的Winform子產品整合後，我們在實際內建項目的時候，就很友善，人員管理子產品就隻有一個WHC.StaffDataDx程式集，不用管理太多關于人員子產品的程式DLL了（否則有UI層、BLL層、DAL層、IDAL層、Entity層等等很多項目工程，這樣一旦子產品分的比較多，幾十個就出來了，非常不便于管理）。
以上就是一個內建測試項目用到的相關應用，我們看到，人員管理子產品裡面隻有一個程式集，其他的是人員管理子產品用到的其他公用子產品，這樣比較友善管理，更利于大型項目的內建工作，不同的子產品職責不同，維護可能也交由不同的技術人員維護即可，而且最大的優點是所有項目都通用，提高重複利用的效率。
內建測試項目是我們實際內建的參考例子，使用很簡單，如下所示。
整個小項目，是我Winform開發架構的縮影，我的Winform開發架構都基本上遵循一個規則來做各獨立子產品的開發，都具有多資料庫支援的特性，良好的架構布局和高品質的代碼特性。
我的傳統Winform開發架構的設計圖，如下所示。其中界面層UI直接通路BLL層，不需要通過網絡，其中公用輔助類庫Common層、實體類層可以在各個層中通路，并把常用的權限管理、字典管理封裝為元件子產品，直接調用，底層則使用工廠方式，來支援各種不同的資料庫，其中UI層、BLL層、DAL層、實體層均使用繼承類方式實作最良好的封裝、最優的代碼設計。
當然下面的架構示意圖也是适用于這個人員管理子產品的了。
實作多資料庫支援的架構項目實際代碼結構如下所示。
他們幾個層之間的關系我在很早介紹架構資料庫結構就介紹過，如下所示。
他們幾個層之間的關系，具有非常強的繼承關系，資料通路層有一個超級基類，抽象于各種資料庫的基礎上而形成，對于不同的資料庫，還有一個一般的基類，用來實作詳細化的資料庫特性，每個業務類，明确繼承關系後，就具有一份非凡的本領（具有幾乎所有常用到的各類通用接口），很多時候我們基本不需要寫任何和資料庫操作的代碼了。
對于界面的設計，一直也希望能比較好的展現出我的設計思想，在整個人員資訊管理中，有人員學習情況、履曆情況、家庭情況、出國情況、職稱情況等，界面基本上比較統一，就是一個清單的管理，正常的管理思路，一般還需要對清單的順序可以自由調整，這是很常見的功能，是以，這裡也引入了一個可以調整順序的GridControlDrager 輔助類，這個就是在使用時，使用者可以拖動記錄到任意的順序。
實作代碼如下所示：
幾個子產品大緻的設計界面如下所示，然後在窗體裡面內建就可以了。
運作時刻的界面效果如下所示。
上篇随筆介紹了Word導出的格式，導出的人員資訊表如下所示：
我們看到，裡面很多資訊是單字段的，有部分是清單的，對于單字段，我們采用在模闆中添加标簽引用方式，然後替換其中的标簽引用的文本實作，如下所示。
對于清單的内容，我們就要引入Aspose.Word的MailMerge功能了，先在固定模闆中插入并定義好相關的域引用，如下所示。
建立一系列的域代碼引用後，才能利用Aspose.Word的MailMerge功能。
上圖紅色部分為對于一個清單必須要建立的域代碼，包括TableStart:和TableEnd的辨別。
建立好這些後，綁定資料源的操作不算複雜，如下所示。
.....................
其中的FillStaticRow函數，我是用來生成固定怎麼多行的操作，使得清單預設不少于固定的函數，否則清單不好看。
以上就是我在開發這個子產品中的一些經驗心得，希望抛磚引玉，對大家有幫助的同時，也能獲得更多的回報意見，互相促進交流。