關於 PHP/Oracle 開發模型如何在Myers Internet縮短應用程序生命周期的案例研究
對於主要由應收款業務模型驅動的公司而言其核心的業務功能之一是輸入跟蹤和記錄訂單在這方面比較出色的公司可以伸縮它們的機構並提高它們的利潤而不會遇到基礎架構的限制當訂單處理很麻煩容易出錯或不一致時公司將因為直接的成本和降低的生產效率而蒙受經濟上的損失
在我的公司 Myers Internet核心的業務事項圍繞著建立客戶基礎為 Myers 提供持續的服務並幫助它在客戶問題出現時解決問題公司正使用許多不同的系統來處理訂單輸入和實施周期的各個方面這些系統既不是彼此集成的也不具備確保每一份訂單都得到正確記帳的機制
Myers 訂單跟蹤系統 (MOTS)
就像其它許多機構一樣Myers 從一個小型公司成長為一個中型公司同時在它的整個成長期間始終保留了相同的過程和系統大多數這些過程在建立時所有的事務處理都通過電子郵件紙質記錄和實地拜訪來人工地完成 或 年前Myers 的一個工程師利用 Allaire 的 Cold Fusion 和一個 Microsoft SQL Server 數據庫組裝了一個系統來跟蹤訂單實施這個系統稱為 MOTS （Myers 訂單跟蹤系統）它允許銷售和帳目管理部門輸入訂單然後由支持工程設計信息系統和會計部門實施這些訂單雖然這個系統是向前邁進的重要的一步但它仍然留有許多人工的步驟並且沒有和任何其它的業務系統集成在一起
大概在同一時間還創建了一個系統在這個系統中客戶和銷售代表可以在線訂購 Myers 網站的產品這個系統可以創建新的 Web 站點並計算提供的 Web 站點程序包的安裝和重復性費用的總和然後它發送電子郵件給各個部門各個部門可以將訂單輸入到 MOTS 中並在帳目管理系統中創建記帳信息
體系結構障礙
這種類型的體系結構飽受幾種系統問題之苦在 Myers較明顯的問題之一包括啟動訂單跟蹤所需的人工數據輸入以及作為這種人工過程的結果而產生的錯誤另一個問題是公司中的訂單輸入訂單跟蹤和記帳系統之間的脫節訂單丟失信息遺漏和其導致的錯誤
另一個僅偶而出現的問題是 MOTS 系統本身有內在的缺陷由於編寫 MOTS 的方式可以輸入沒有部門分配信息或者丟失了部門分配信息的訂單當這種情況發生時訂單最終將在系統中丟失當訂單丟失時准確及時的記帳就更難實現了
隨著業務的成長體系結構中的缺陷變得越來越明顯並且隨著客戶和訂單數量的增加丟失和錯誤輸入的訂單出現的頻率越來越高從而給公司收入帶來了難於估量的影響此外人工輸入的數據的數量導致了延遲和處理效率低下
由於在實施機構內對收入的影響加大和效率降低很明顯必須要有一個替換系統來將一切聯系起來並提高效率和降低錯誤率舊系統圖示如下
圖 舊的系統體系結構
該圖顯示了需要人工數據輸入的所有區域由於這些系統都不是集成的所以數據丟失或失真的可能性非常大全局需求馬上變得明顯起來
訂單系統需要直接和實施跟蹤系統聯系起來該系統需要安全保護來防止訂單在未經處理之前脫離系統需要保持精確性以確保准確的記帳和正確的訂單實施系統需要使內部成本最小化所以要達到那個目的需要快速地創建系統但系統必須擁有完整的功能
雖然一個好的訂單輸入和跟蹤系統可以幫助降低成本但它本身並不創造收入
深入結構
在開始模式設計之前需要解決一些基本的體系結構問題第一個底層的技術需求是系統必須可配置且無需額外的編碼本質上這意味著需要把工作流嵌入到數據庫中而不是用解釋/處理代碼來進行硬編碼第二數據庫需要包含足夠的信息以便能夠表現訂單輸入界面的主要（和可更改）的方面以及實施處理
在努力解決上述問題的過程中該系統逐漸適合於兩個部分 — 訂單輸入和訂單跟蹤並在兩者之間提供了明確定義的聯系訂單輸入系統需要知道如何用准確的產品代碼折扣和定價條款來表示訂單訂單實施系統需要知道如何跟蹤各種類型的任務相關的作業和各個部門以處理和記錄每份訂單最後需要定期和可預測地把訂單轉化成實施作業下圖顯示了目前存在的新系統的結構
圖 新的系統體系結構
該圖顯示了通向新的訂單系統的所有信息路徑新的訂單系統位於後端的門戶管理站點所有的初始數據輸入都僅一次性完成並且只需要每個小組在處理的各個階段驗證數據通過引入從訂單系統到帳目管理系統的自動數據傳輸至關重要的數據傳輸的另一個主要的領域也變為自動化
依賴 PHP
在純技術的層面上早期決定使用 PHP 作為主要的開發語言和 Oracle 作為系統的數據信息庫這有幾個主要的原因首先Myers 現有的後端門戶幾乎完全是用 PHP 根據一個現有的 Oracle 數據庫編寫的這消除了一個產生不兼容性的潛在來源這還意味著要創建這個新的系統Myers 可以利用自身的能力這些能力創建了現有的後端門戶
第二實驗測試顯示與其它開發語言相比PHP 提供了一個比較高的性能水平因為 PHP 是作為一個動態加載的資料庫駐留在 Apache 服務器內部的所以每一次與系統連接都無需額外的啟動時間此外PHP 優化的改善（通過 Zend 項目）意味著在代碼內部執行的一般操作不會明顯變慢最後為 PHP 編寫的 OCI 接口模塊是用 C 代碼編譯和優化的這使得訪問 Oracle 數據庫非常高效
第三我們了解到因為 PHP 代碼將其自身嵌入到了 HTML 環境中所以對於設計人員和編程人員而言創建協作用戶接口功能代碼變得更加自然雖然最後這個特性其它的服務器端腳本語言也具備但 Myers 發現 PHP 更不可能帶來開發人員和設計人員之間的沖突此外PHP 的語法和提供的代碼庫意味著它可以做它需要做的所有事情
最後將所有代碼嵌入到 HTML 代碼中的另一個好處是僅需要對標准文本文件進行修改控制就可以控制源代碼我們用 CVS 作為它的標准修改控制系統因為 PHP 代碼不一定要用某一種方式進行編譯所以創建系統的一次編譯僅涉及到從信息庫中檢索文本源代碼文件然後把它們放到 web 服務器上這意味著我們可以使用 CVS 中的控制機制為它的測試和生產環境發布增量的 bug 補丁而無需創建復雜的編譯系統
設計模式來支持可重新配置性
下面的基本模式示意圖顯示了訂單系統是如何構建的兩種主要的模式都分為原型表和事務表無論何時當業務情況發生變化時原型表都允許重新配置系統而無需重新編碼事務表包含實際客戶訂單的訂單詳情和作業詳情
圖 基本模式示意圖
圖 基本模式示意圖
這些模式示意圖看起來很復雜當然它們的確很復雜不過如果把它們分開使得只出現原型表（以 _def 結束的表）那麼該體系結構的基本結構就變得很清楚了訂單由行組組成這些行組包括詳細信息訂單行或兩者訂單行可以隨意地創建作業作業由一個任務序列組成並且包含幾條詳細信息必需要為各種任務輸入這些詳細信息任務出現在不同的隊列中這些隊列可以由不同部門的特定用戶進行訪問
為了檢驗系統策略是分階段將訂單系統原型化系統要檢驗的第一部分是它單獨從訂單原型表中創建一份清楚的訂單的能力一旦完成了最初的模式定義訂單生成器就是原形化的系統的第一個可視部分
為構建和配置這個系統而組成的小組除含受這個系統影響最大的各個部門的經理之外還包括三個開發人員開發人員的分工分別為構建配置功能顯示功能和事務處理功能在整個最初的構建周期內部門經理提供了關於界面（這些界面使用戶能夠輸入和處理數據）類型的有價值的反饋
利用 PHP 繪制用戶界面
要原型化的初始訂單是基本的 Web 站點訂單在 webw/ 上提供得到的訂單是由一個開發人員用 PHP 在三天的時間內創建的如果訂單原型定義 — 依靠只在數據庫和浏覽器之間的一層 PHP 代碼就能夠完全定義訂單輸入的外觀和行為那麼在數據庫設計中需要一定程度的折衷為此諸如訂單行組之類的結構必須支持兩個用途() 在輸入表單上提供可視化的區分以使類似的產品組可以繪制在一起 () 從功能上對類似的商品分組比如說打了一定折扣的商品或一個選項列表從中可以作出唯一的選擇
因為 PHP 是開發語言所以原型組建相當快速從而可以快速地完成模式所需的修改並且為表單生成器重新編碼（一前一後）此外因為模式是考慮了繪制的用戶界面而設計的所以當在原型構建過程中出現新的可視化需求時可以容易地進行模式修改和改編生成的表單外觀與下圖相似
圖 訂單生成
創建一個功能完全的系統
在提供訂單之後需要使它變得功能完全首先系統需要保存在訂單中輸入的用於事務處理的訂單數據第二填寫訂單的人需要能夠根據正在進行中的訂單數據來填寫
From:http://tw.wingwit.com/Article/program/Oracle/201311/16649.html
