Word自動化局部架構設計（轉InfoQ）

時間 2019-12-17

標籤 word 自動化局部架構設計 infoq 欄目 Microsoft Office 简体版

原文原文鏈接

閱讀: 196 評論: 1 做者: 周金根發表於 2010-05-26 09:24 原文連接html

前言

雖然企業中多數項目每每經過自定製的界面和數據載體與後臺系統交互，但在辦公自動化、電子政務領域仍存在大量面向包括Word在內的電子文檔操做。區別於Excel、Access和InfoPath等數據爲中心的處理，Word更側重於對於文章段落內容、格式的操做。編程

實踐中，Office自動化開發中每每要面對下列挑戰：安全

Office版本更新快，但用戶羣更新相對較慢，項目中須要同時兼容多個版本，但Office產品不一樣版本間接口兼容性常常斷裂；
單機版Office軟件容易由於格式錯誤致使運行錯誤，相關進程不妥善清理很容易破壞文檔形成沒法修復的問題；
面對日益嚴峻的信息安全問題，不少企業內網安全策略會禁用Office宏、內嵌腳本和客戶端渲染的處理；
第三方Office中間件技術支持力量每每沒法保障，尤爲是部分開源項目其適用性有限，且常常存在沒法繞過的「黑盒」By Design問題，最終不得不放棄該中間件並推倒整個設計重作。

但同時咱們也要看到Word自動化處理中的特色：架構

Word提供模板機制，能夠經過模板完成絕大部分章節段落以及文稿樣式的設計；
儘管原始數據類型差異迥異，但實際Word操做中使用的類型主要是string，圖形、圖表對象則可考慮集成Visio或Excel完成；
文檔數據填充形式相對固定，通常是下列三種狀況之一或組合：
操做一系列單獨的內容區域；
操做一個表格區域；
操做單一區域。

針對上述特色，爲便於重複開發量、便於開發人員訪問Word文檔須進行局部架構設計。框架

定義書籤

但在此以前，爲了簡化Word編程，本框架針對Bookmark訪問並操做Word，定義方法以下：ide

一、打開word文件，選擇顯示Bookmark網站

二、選擇位置，而後插入Bookmark。對於須要操做的表格區域能夠選擇整個區域後插入Bookmark。spa

局部架構設計

抽象角度看，Word自動化過程可歸併爲「讀」、「處理」和「寫」三個主要過程，其基本工做原理以下：架構設計

圖：局部架構的工做原理設計

其中：

Reader根據數據文件類型及數據內容特色完成數據提取；
Writer根據目標文檔類型及數據內容特色完成數據寫入；
Adapter根據文檔處理情景選擇Reader和Writer，實現數據和文檔的合併過程；
Task Scheduler根據處理負載通知Adapter執行處理；（該部分用於擴展Word自動化爲後臺任務時定製處理過程）。

邏輯組件關係以下：

圖：Word自動化處理主要組件

其中：

Common.dll保存一些公共功能的編譯結果；
Automation.dll提供對Office對象的（包括Word）的封裝；
Integration.Interface.dll則提供外部Adapter的規範性要求以及進一步擴展的基礎；
而真正的Adapter則獨立在框架外，經過配置IoC加載到執行環境中。

適配器部分

考慮不一樣項目對Word自動化處置的差別性，設計上將Adapter獨立於應用以外，同時將每一個Adapter須要執行的操做盡可能固定，這樣對於常規操做只需調用標準Reader和Writer便可。

（注：此外，考慮到自動化處理中文檔內容的差別性，根據項目實踐爲提升數據的擴展性，通常推薦採用XML形式的數據文件。）

設計上，咱們先抽象文檔操做對象Adapter的行爲接口，定義所需的數據與文檔合併（Merge）操做：

圖：適配器邏輯結構

其中：

IDocumentAdapter定義基本的行爲，其內容甚至能夠在沒有Reader和Writer的環境下完成合並工做，全部行爲能夠由用戶程序獨立定義；
IGenericDocumentAdapter則提供基本的操做行爲，其中經過泛型參數定義Reader反饋的數據類型以及它對應的字符串類型；
DocumentAdapterBase做爲實際Adapter的抽象類型，不只提供對應配置節的內容，同時進一步補充Reader所提取實體內容的泛型參數。

這樣，經過對Adapter的三層封裝，下游程序開發人員能夠根據自動化情形的複雜程度選擇適合的擴展基礎。進一步，咱們對Reader和Writer進行擴展，提供標準情景下標準數據類型的讀寫操做。

圖：Reader部分的邏輯結構

其中：

Reader部分默認提供針對實體組（Tabular表格）、具備多屬性的單個實體（List列表）和單值實體（String）的讀取支持，更復雜數據的讀取工做能夠經過組合上述Reader類型或直接實現IDataReader接口完成；
爲了提供對XML數據的內置支持，提供基於XPath的封裝類型。

圖：Writer部分的邏輯結構

對於Writer部分：

考慮到表格內容和單值內容都可經過一個Bookmark定位，所以抽象出IBookmarkRangeWriter接口用於提供對這兩類Writer的定製操作；
對於多值實體（List），因爲它的寫入須要一組Bookmark定位，所以抽象出IBookmarkListRangeWriter接口對該類Writer的操做；

自動化部分

在完成了外部調用關係的設計後，咱們須要完成Word自動化的核心部分——經過Office Primary Interop Assembly(Office PIA)訪問Word的基本操做。

圖：項目中引用Office的PIA庫

實際使用中，Word對象模型以下：

圖：Word Object Model（摘自MSDN Microsoft Visual Studio Tools for the Microsoft Office system (version 3.0) 部分）

其中，Application表明一個WinWord.exe進程，對其打開關閉代價較大，頻繁的打開、關閉勢必會對後臺文檔自動化帶來較大的運行負載，爲此，須要集中控制。而每一個Word文檔能夠經過Document得到引用，而後經過Bookmark檢索到對應的區域(Range)，進而經過Writer操做Range對象，填充、清除、修改該區域的內容。此外，考慮到相似電子表格的合併操做，每每外部數據記錄數量超過Word模板（或文檔）表格區域的大小，爲此還需增長必要的Add Row方法、Add Column方法，本文示例爲了簡便，只設計了Add Row方法。

綜上，Word自動化部分設計以下：

圖：Word自動化部分設計

配置

爲了減小客戶端程序的工做量，常見的操做參數保存在配置文件中，這樣咱們定義整個模型的自定義配置節以下：

圖：配置對象

其餘

雖然直接調用Word PIA接口能夠較快的完成一個具體Word自動化處理，但隨着用戶需求的變化，該類項目每每必須面臨常常性的修改，爲了儘可能將修改控制在局部、提升下游開發人員的使用效率，通常能夠經過對局部進行架構建模提高自動化框架的靈活性，而額外的工做量主要集中在抽象出Reader、Writer和根據文檔操做目標定義相關的Adapter。