談談我對MySQL+PHP+Flex開發的見解

說起用MySQL+PHP+Flex來編寫網路程式和應用,不少人會覺得非常地非主流，之所以選擇這一套解決方案，也是有原因的。首先說MySQL。相比DB2、Oracle這些商業資料庫，MySQL的最大優勢就在於它的免費特性。由於我的大部分應用都非常Personal，不太可能涉及到所謂的“大規模商業應用”，所以MySQL對我而言已經完全夠用了（相信對大多數人而言也是夠用了，況且還有很多所謂的企業級系統也在使用MySQL資料庫）；相比PostgreSQL之類的其他免費開源資料庫，雖然可能有比MySQL效能更強的資料庫存在，但是MySQL無疑是最普及的資料庫，如果日後要使用虛擬主機之類服務的租用資料庫，MySQL無疑也是成本最低的。

其次說PHP。同樣，PHP也是免費開源的，但是在伺服器端程式中，PHP的功能遠遠不如另外一種開源語言——JAVA來的完善。之所以選擇PHP，主要還是看中了它的執行速度。畢竟在我這種Personal的應用下，JAVA過於強大的功能顯然是殺雞用牛刀。既然都能夠達到，那有為何不選擇效率更高的PHP呢？更何況Linux+Apache+MySQL+PHP的LAMP組合正越來越流行，以至於將MySQL與PHP一起部署非常容易，何樂而不為呢？

最後是Flex。由於需要FlashPlayer的支援，同樣作為RIA解決方案的Flex的適應性顯然沒有Ajax來的強，但是考慮到Flex不像Javascript，Flex有Adobe的支援，標準相對比較統一，而且Flashplayer的裝機率達到了98%以上，而且具有非常強的跨平臺能力，部署上應該不會有太大的問題，反倒是Javascript由於各方面的利益關係，可能在不久的將來發生分化。此外，Flex的表現力堪比C/S架構軟體，遠遠強於Ajax。

好了，說完了使用FPM組合的原因，接下來再談談這兩年中開發FPM應用的經驗吧。由於缺少合作者，兩年來我的所有非開源專案都是我一個人完成的，所以三個部分應該都有些可以分享的經驗。資料庫方面的經驗已經非常系統了，學校裡也有相關的課程系統的學習，所以這裡也不好意思多說，這裡主要說說Flex和Php開發的經驗。

對於開發軟體系統，我有一條自己的宗旨，即就是“軟體的每一種操作都是對現實中的某個流程的抽象”。根據這一理念，我在開發一個軟體之前，都會把要管理的業務的所有流程總結一下，畫出一張巨大的、儘可能詳細的流程表（比如一個線上租車系統，除了下訂單，提車，還車之類的“主要流程”，汽車損壞、退款、索賠這類的“非主要流程”也要考慮在內），這個看似與軟體開發無關的過程往往要花費2~3天的時間，而且據我的經驗，這甚至是整個開發過程中對最終軟體的功能性和穩定性影響最大的一個步驟。

然後，從大的流程表裡面遴選出需要用軟體進行抽象的步驟。沒有一個軟體能夠覆蓋某個系統中的所有業務，不然的話我們就可以做出“無人服務公司”了。事實上，即使是淘寶這類高度電子化的交易業務，也需要一大批人來處理糾紛、提供諮詢。所以，我們要做的從大業務流程圖中選取出最常用、最需要電子化管理的流程子集，繪製出一張用於編寫軟體的小業務流程圖來。

有了這張小業務流程圖，軟體的需求就明確了（在傳統的軟體工程中，這一部分的分析往往應該用客戶完成，但是對於Personal的系統，使用者本人可能也並不是很明確他們的需求，所以這部分工作也需要我們代勞）。接下來就應該是具體的軟體設計了。我的經驗是，軟體設計要從介面開始，然後是資料庫，最後才是伺服器端程式。按照常規的思路，本來應該是資料庫先行的，但是同樣由於我們的需求並不是很明確，新的資料元素和資料關係隨時都可能出現，尤其是當我們在設計客戶端介面的時候，很可能會發現一些之前沒有想到的元素。所以，如果介面設計在資料庫設計之後的話，很可能會在介面設計階段大規模修改資料庫結構，或者為了適應資料庫設計而犧牲使用者體驗和功能，而把介面設計作為在畫完小業務流程圖之後的第一步的話，由於業務流程圖的思維是完全符合“使用者思維習慣”的，而不是資料庫的“程式設計師思維習慣”，所以設計出的介面會更加人性化，更加易用。

當我們有了介面之後，資料庫的設計就有了明確的需求和目標，再過複雜的應用也不會太傷腦筋（事實上，大部分所謂傷腦筋的問題都是我們自己對問題本身不明確而導致的）。剩下的事就是如何把介面和資料庫連線起來的事了，也就是伺服器端程式的設計。

根據我的經驗，用PHP構建的伺服器端程式並不適合使用完全的物件導向設計，因為物件的成員函式處理比常規函式或是靜態函式要慢許多，如果過分地依賴物件導向的機制，會使最終的程式效率低得驚人，甚至連JAVA(JSP)都不如。（對於這一點，我是有“血的教訓”的）。如果你既想提高程式效率，又不想犧牲物件導向的機制或者想使用一些設計模式的話，最好的解決辦法就是把儘可能多的函式寫成靜態函式，然後依舊用你的物件導向思維。

具體到設計細節上，PHP伺服器端程式設計又最好能夠分為資料層和業務層。其中資料層用於把所有的資料庫操作包裝成函式，從而向上遮蔽SQL語句（這也是被廣泛地證明有效的一種設計方法）；業務層則通過呼叫資料層的一個或若干個函式來處理來自客戶端的每一種請求，並將結果包裝成客戶端可以理解的HTTPService或者WebService的形式。

還有客戶端和伺服器的通訊。我個人的感覺是，對於一個Personal的系統，一組上行使用HTTP-POST，下行使用XML或String的HTTPService就夠用了，完全沒有必要將伺服器端包裝成WebService。這裡我一再提到Personal一詞，就是為了說明至始至終我們的服務物件都不是高階企業使用者，WebService是為了方便多個系統之間進行通訊的，對於我們這樣的小系統完全沒有必要，只會增加設計的難度和成本。在Flex一端，我的經驗是每一類應用的通訊單獨寫一個類，其中包含該類所有操作的HTTPService、結果分析函式和錯誤分析函式，然後在主程式中為每個類生成一個例項。用於隨時通訊及訪問資料。

最後是Flex方面的使用者互動設計。由於使用者互動設計往往涉及到資料通訊，所以無法再介面的初步設計階段完成。使用者互動設計往往要放在通訊部分構建完成之後，所以也往往是設計過程的最後一步。這裡，我的經驗是把所有的使用者互動函式分類寫在單獨的AS檔案中，然後在主檔案中引用。

好了，以上是我的一些粗淺見解，希望能夠拋磚引玉。請大家多多灌水，多多指教~