推薦：PHP實(shí)例：用PHP實(shí)現(xiàn)表單驗(yàn)證碼登陸校驗(yàn)
原理：生成一個圖片,并且保存圖片中顯示的字符到SESSION.在登陸時(shí)判斷輸入的校驗(yàn)碼是否和SESSION中校驗(yàn)碼相同。 這是生成校驗(yàn)碼和圖片的文件checkNumber.php

關(guān)于 PHP/Oracle 開發(fā)模型如何在Myers Internet縮短應(yīng)用程序生命周期的案例研究。

對于主要由應(yīng)收款業(yè)務(wù)模型驅(qū)動的公司而言，其核心的業(yè)務(wù)功能之一是輸入、跟蹤和記錄訂單。在這方面比較出色的公司可以伸縮它們的機(jī)構(gòu)，并提高它們的利潤，而不會遇到基礎(chǔ)架構(gòu)的限制。當(dāng)訂單處理很麻煩、容易出錯或不一致時(shí)，公司將因?yàn)橹苯拥某杀竞徒档偷纳�產(chǎn)效率而蒙受經(jīng)濟(jì)上的損失。

在我的公司 Myers Internet，核心的業(yè)務(wù)事項(xiàng)圍繞著建立客戶基礎(chǔ)，為 Myers 提供持續(xù)的服務(wù)并幫助它在客戶問題出現(xiàn)時(shí)解決問題。公司正使用許多不同的系統(tǒng)來處理訂單輸入和實(shí)施周期的各個方面。這些系統(tǒng)既不是彼此集成的，也不具備確保每一份訂單都得到正確記帳的機(jī)制。

Myers 訂單跟蹤系統(tǒng) (MOTS)

就像其它許多機(jī)構(gòu)一樣，Myers 從一個小型公司成長為一個中型公司，同時(shí)在它的整個成長期間始終保留了相同的過程和系統(tǒng)。大多數(shù)這些過程在建立時(shí)，所有的事務(wù)處理都通過電子郵件、紙質(zhì)記錄和實(shí)地拜訪來人工地完成。5 或 6 年前，Myers 的一個工程師利用 Allaire 的 Cold Fusion 和一個 Microsoft SQL Server 數(shù)據(jù)庫組裝了一個系統(tǒng)來跟蹤訂單實(shí)施，這個系統(tǒng)稱為 MOTS （Myers 訂單跟蹤系統(tǒng)），它允許銷售和帳目管理部門輸入訂單，然后由支持、工程、設(shè)計(jì)、信息系統(tǒng)和會計(jì)部門實(shí)施這些訂單。雖然這個系統(tǒng)是向前邁進(jìn)的重要的一步，但它仍然留有許多人工的步驟，并且沒有和任何其它的業(yè)務(wù)系統(tǒng)集成在一起。

大概在同一時(shí)間，還創(chuàng)建了一個系統(tǒng)，在這個系統(tǒng)中客戶和銷售代表可以在線訂購 Myers 網(wǎng)站的產(chǎn)品。這個系統(tǒng)可以創(chuàng)建新的 Web 站點(diǎn)，并計(jì)算提供的 Web 站點(diǎn)程序包的安裝和重復(fù)性費(fèi)用的總和。然后它發(fā)送電子郵件給各個部門，各個部門可以將訂單輸入到 MOTS 中，并在帳目管理系統(tǒng)中創(chuàng)建記帳信息。

體系結(jié)構(gòu)障礙

這種類型的體系結(jié)構(gòu)飽受幾種系統(tǒng)問題之苦。在 Myers，較明顯的問題之一包括啟動訂單跟蹤所需的人工數(shù)據(jù)輸入，以及作為這種人工過程的結(jié)果而產(chǎn)生的錯誤。另一個問題是公司中的訂單輸入、訂單跟蹤和記帳系統(tǒng)之間的脫節(jié)、訂單丟失、信息遺漏和其導(dǎo)致的錯誤。

另一個僅偶而出現(xiàn)的問題是 MOTS 系統(tǒng)本身有內(nèi)在的缺陷。由于編寫 MOTS 的方式，可以輸入沒有部門分配信息或者丟失了部門分配信息的訂單。當(dāng)這種情況發(fā)生時(shí)，訂單最終將在系統(tǒng)中丟失。當(dāng)訂單丟失時(shí)，準(zhǔn)確、及時(shí)的記帳就更難實(shí)現(xiàn)了。

隨著業(yè)務(wù)的成長，體系結(jié)構(gòu)中的缺陷變得越來越明顯，并且隨著客戶和訂單數(shù)量的增加，丟失和錯誤輸入的訂單出現(xiàn)的頻率越來越高，從而給公司收入帶來了難于估量的影響。此外，人工輸入的數(shù)據(jù)的數(shù)量導(dǎo)致了延遲和處理效率低下。

由于在實(shí)施機(jī)構(gòu)內(nèi)對收入的影響加大和效率降低，很明顯必須要有一個替換系統(tǒng)來將一切聯(lián)系起來，并提高效率和降低錯誤率。舊系統(tǒng)圖示如下。

圖 1：舊的系統(tǒng)體系結(jié)構(gòu)

該圖顯示了需要人工數(shù)據(jù)輸入的所有區(qū)域。由于這些系統(tǒng)都不是集成的，所以數(shù)據(jù)丟失或失真的可能性非常大。全局需求馬上變得明顯起來。

訂單系統(tǒng)需要直接和實(shí)施跟蹤系統(tǒng)聯(lián)系起來。該系統(tǒng)需要安全保護(hù)來防止訂單在未經(jīng)處理之前脫離系統(tǒng)。需要保持精確性，以確保準(zhǔn)確的記帳和正確的訂單實(shí)施。系統(tǒng)需要使內(nèi)部成本最小化。所以，要達(dá)到那個目的，需要快速地創(chuàng)建系統(tǒng)，但系統(tǒng)必須擁有完整的功能。

雖然一個好的訂單輸入和跟蹤系統(tǒng)可以幫助降低成本，但它本身并不創(chuàng)造收入。

深入結(jié)構(gòu)

在開始模式設(shè)計(jì)之前，需要解決一些基本的體系結(jié)構(gòu)問題。第一個底層的技術(shù)需求是系統(tǒng)必須可配置，且無需額外的編碼。本質(zhì)上，這意味著需要把工作流嵌入到數(shù)據(jù)庫中，而不是用解釋/處理代碼來進(jìn)行硬編碼。第二，數(shù)據(jù)庫需要包含足夠的信息，以便能夠表現(xiàn)訂單輸入界面的主要（和可更改）的方面以及實(shí)施處理。

在努力解決上述問題的過程中，該系統(tǒng)逐漸適合于兩個部分 — 訂單輸入和訂單跟蹤，并在兩者之間提供了明確定義的聯(lián)系。訂單輸入系統(tǒng)需要知道如何用準(zhǔn)確的產(chǎn)品代碼、折扣和定價(jià)條款來表示訂單。訂單實(shí)施系統(tǒng)需要知道如何跟蹤各種類型的任務(wù)、相關(guān)的作業(yè)和各個部門，以處理和記錄每份訂單。最后，需要定期和可預(yù)測地把訂單轉(zhuǎn)化成實(shí)施作業(yè)。下圖顯示了目前存在的新系統(tǒng)的結(jié)構(gòu)。

圖 2：新的系統(tǒng)體系結(jié)構(gòu)

該圖顯示了通向新的訂單系統(tǒng)的所有信息路徑，新的訂單系統(tǒng)位于后端的門戶管理站點(diǎn)。所有的初始數(shù)據(jù)輸入都僅一次性完成，并且只需要每個小組在處理的各個階段驗(yàn)證數(shù)據(jù)。通過引入從訂單系統(tǒng)到帳目管理系統(tǒng)的自動數(shù)據(jù)傳輸，至關(guān)重要的數(shù)據(jù)傳輸?shù)牧硪粋�主要的領(lǐng)域也變?yōu)樽詣踊��?/p>

依賴 PHP

在純技術(shù)的層面上，早期決定使用 PHP 作為主要的開發(fā)語言和 Oracle 作為系統(tǒng)的數(shù)據(jù)信息庫，這有幾個主要的原因。首先，Myers 現(xiàn)有的后端門戶幾乎完全是用 PHP 根據(jù)一個現(xiàn)有的 Oracle 數(shù)據(jù)庫編寫的，這消除了一個產(chǎn)生不兼容性的潛在來源。這還意味著要創(chuàng)建這個新的系統(tǒng)，Myers 可以利用自身的能力，這些能力創(chuàng)建了現(xiàn)有的后端門戶。

第二，實(shí)驗(yàn)測試顯示，與其它開發(fā)語言相比，PHP 提供了一個比較高的性能水平。因?yàn)?PHP 是作為一個動態(tài)加載的資料庫駐留在 Apache 服務(wù)器內(nèi)部的，所以每一次與系統(tǒng)連接都無需額外的啟動時(shí)間。此外，PHP 優(yōu)化的改善（通過 Zend 項(xiàng)目）意味著在代碼內(nèi)部執(zhí)行的一般操作不會明顯變慢。最后，為 PHP 編寫的 OCI 接口模塊是用 C 代碼編譯和優(yōu)化的，這使得訪問 Oracle 數(shù)據(jù)庫非常高效。

第三，我們了解到因?yàn)?PHP 代碼將其自身嵌入到了 HTML 環(huán)境中，所以對于設(shè)計(jì)人員和編程人員而言，創(chuàng)建協(xié)作用戶接口功能代碼變得更加自然。雖然最后這個特性其它的服務(wù)器端腳本語言也具備，但 Myers 發(fā)現(xiàn) PHP 更不可能帶來開發(fā)人員和設(shè)計(jì)人員之間的沖突。此外，PHP 的語法和提供的代碼庫意味著它可以做它需要做的所有事情。

最后，將所有代碼嵌入到 HTML 代碼中的另一個好處是，僅需要對標(biāo)準(zhǔn)文本文件進(jìn)行修改控制就可以控制源代碼。我們用 CVS 作為它的標(biāo)準(zhǔn)修改控制系統(tǒng)。因?yàn)?PHP 代碼不一定要用某一種方式進(jìn)行編譯，所以創(chuàng)建系統(tǒng)的一次“編譯”僅涉及到從信息庫中檢索文本源代碼文件，然后把它們放到 web 服務(wù)器上。這意味著我們可以使用 CVS 中的控制機(jī)制為它的測試和生產(chǎn)環(huán)境發(fā)布增量的 bug 補(bǔ)丁，而無需創(chuàng)建復(fù)雜的編譯系統(tǒng)。

設(shè)計(jì)模式來支持可重新配置性

下面的基本模式示意圖顯示了訂單系統(tǒng)是如何構(gòu)建的。兩種主要的模式都分為原型表和事務(wù)表。無論何時(shí)當(dāng)業(yè)務(wù)情況發(fā)生變化時(shí)，原型表都允許重新配置系統(tǒng)，而無需重新編碼。事務(wù)表包含實(shí)際客戶訂單的訂單詳情和作業(yè)詳情。

圖 3：基本模式示意圖

圖 4：基本模式示意圖

這些模式示意圖看起來很復(fù)雜，當(dāng)然，它們的確很復(fù)雜。不過，如果把它們分開，使得只出現(xiàn)原型表（以 _def 結(jié)束的表），那么該體系結(jié)構(gòu)的基本結(jié)構(gòu)就變得很清楚了。訂單由行組組成，這些行組包括詳細(xì)信息、訂單行或兩者。訂單行可以隨意地創(chuàng)建作業(yè)，作業(yè)由一個任務(wù)序列組成，并且包含幾條詳細(xì)信息。必需要為各種任務(wù)輸入這些詳細(xì)信息。任務(wù)出現(xiàn)在不同的隊(duì)列中，這些隊(duì)列可以由不同部門的特定用戶進(jìn)行訪問。

為了檢驗(yàn)系統(tǒng)，策略是分階段將訂單系統(tǒng)原型化。系統(tǒng)要檢驗(yàn)的第一部分是它單獨(dú)從訂單原型表中創(chuàng)建一份清楚的訂單的能力。一旦完成了最初的模式定義，訂單生成器就是原形化的系統(tǒng)的第一個可視部分。

為構(gòu)建和配置這個系統(tǒng)而組成的小組除含受這個系統(tǒng)影響最大的各個部門的經(jīng)理之外，還包括三個開發(fā)人員。開發(fā)人員的分工分別為：構(gòu)建配置功能、顯示功能和事務(wù)處理功能。在整個最初的構(gòu)建周期內(nèi)，部門經(jīng)理提供了關(guān)于界面（這些界面使用戶能夠輸入和處理數(shù)據(jù)）類型的有價(jià)值的反饋。

利用 PHP 繪制用戶界面

要原型化的初始訂單是基本的 Web 站點(diǎn)訂單，在 webwiz.myersinternet.com/ 上提供。得到的訂單是由一個開發(fā)人員用 PHP 在三天的時(shí)間內(nèi)創(chuàng)建的。如果訂單原型定義 — 依靠只在數(shù)據(jù)庫和瀏覽器之間的一層 PHP 代碼，就能夠完全定義訂單輸入的外觀和行為，那么在數(shù)據(jù)庫設(shè)計(jì)中需要一定程度的折衷。為此，諸如訂單行組之類的結(jié)構(gòu)必須支持兩個用途：(1) 在輸入表單上提供可視化的區(qū)分，以使類似的產(chǎn)品組可以繪制在一起 (2) 從功能上對類似的商品分組，比如說打了一定折扣的商品，或一個選項(xiàng)列表，從中可以作出唯一的選擇。

因?yàn)?PHP 是開發(fā)語言，所以原型組建相當(dāng)快速，從而可以快速地完成模式所需的修改并且為表單生成器重新編碼（一前一后）。此外，因?yàn)槟Ｊ绞强紤]了繪制的用戶界面而設(shè)計(jì)的，所以當(dāng)在原型構(gòu)建過程中出現(xiàn)新的可視化需求時(shí)，可以容易地進(jìn)行模式修改和改編。生成的表單外觀與下圖相似：

圖 5：訂單生成

創(chuàng)建一個功能完全的系統(tǒng)

在提供訂單之后，需要使它變得功能完全。首先，系統(tǒng)需要保存在訂單中輸入的用于事務(wù)處理的訂單數(shù)據(jù)。第二，填寫訂單的人需要能夠根據(jù)正在進(jìn)行中的訂單數(shù)據(jù)來填寫。

分享：PHP實(shí)例：PHP取GB2312編碼字符串首字母的方法
以下為引用的內(nèi)容： <?php /* * @author: [email protected] */ $dict=array( 'a'=>0xB0C4, 'b'=>0xB2C0, 'c'=>0xB4ED,