Web程式設計語言 之 我選擇我喜歡

1. Python+Web

這幾天就憋在房子裡搞Web編程，進行語言的選擇、架構的選擇，把頭弄得都暈了。因為對Python比較熟悉，先看Python下進行Web編程如何。

Python下的Web架構是最多的，越多就越不容易挑選，你要對每種架構都進行研究後才能給出結論，最後選定Django進行了皮毛的研究。發現真要開發起來還是比較煩人的，涉及的東西太多了。後來又看了看其他輕量級的架構如mod_python，webpy等等感覺容易上手一些。

這隻是從技術上進行可行性分析，但想到國內支援Python的Web主機，簡直是少了又少，從商用、環境、成熟度等級角度來看，我們開發短平快的項目不適合用Python。

2. Java+web

既然Python不太適合，那Java如何？Java沒的說，那麼多人用他肯定有的長處，對我來說呢？我是從C＋＋/Delphi過來的，對Java也不陌生，但總的來說不算太熟，特別是對於J2EE那恐怖的大架構，裡面的類庫簡直太恐怖了，你為了完成一個簡單的功能，得用幾十個類才能完成。我曾用Struts＋Hibernate開發過一個簡單的使用者自助服務系統，光裡面的配置都快把人弄瘋了。你正在做相關項目的時候可以費點勁把這些知識拾起來，把開發工具（Eclipse）搭起來，但時間一久就差不多忘了，又得在網上好一番狂搜。就說Eclipse吧，我們要用Hibernate的外掛程式來做Hibernate的配置，資料庫的映射等，第一次配置的時候是從按照網上找的資料進行的，等項目開發完了，大家都忙別的事情去了；幾個月後要將資料庫移植到Oracle，這時候再來搭環境吧，由於在這幾個月之內大家都在用其他的語言開發，早就忘了怎麼搭了，又得找半天才把環境搭起來。環境搭起來了吧，Hibernate是怎麼一回事又忘了，還得拿出《精通Hibernate》進行一次學習。

換個角度，如果我們一直都在用Java開發，這個不是問題，但很多像我們一樣的朋友一直在Win32上開發而現在要轉到Web下的，並且時不時還要重操舊器（Win32），Java的大架構對我們來說是個很大的“山”。實話來講，對於小的用於自己產品的項目來說，不用計較開發語言多強大，只要夠用就好。因為引進新的開發語言或工具，勢必造成人力資源的浪費，而為自己幹活不能不考慮成本。結論是：Java架構太大、太複雜，我們要花太大的代價、精力來“利”這個“器”，如果有更好的選擇，暫不考慮Java。

3. ASP.net+web

那剩下來的還有什麼選擇呢？ASP，ASP.Net，C#？對於此ASP類的我是不打算去用的。我也知道有微軟強大的Visual Studio開發工具，ASP類的Web開發會如虎添翼，並且ASP類語言入門難度很低，但考慮到我們的產品必須要支援類Unix平台，只這一條就不用考慮ASP類了。但是，具體情況具體分析，對於不要求跨平台的項目我們還是可以選擇ASP的。

不選擇ASP的另外一個理由是，產品的自身安全性。雖說現在都是賣服務不賣產品，但具體到不同的商業模式可能就不可一概而論了。而ASP本身好像不能進行代碼的加密，也就是說你給客戶部署的應用，別人能直接修改你的ASP代碼。這點我從網上找到的一些資訊可以隱約感覺到，一般一個好的網站出來以後，如果用的ASP，那麼類似的網站很快就會複製；我們也可以從網上下載到現成的整站代碼，幾乎不用修改就可以使用了。如果我們的產品採用ASP開發，那競爭者不就可以直接拿過來換張皮就用，加密好像不怎麼好做啊。當然上面所說的ASP加密問題，這個我沒具體研究，也許有解決的方案吧。

結論：由於ASP不支援跨平台，沒有足夠的安全保障，不能選擇ASP。

4. PHP+web4.1. 選擇學習PHP

那剩下的選擇就不多了，最終目光放在了PHP上。

PHP是個動態指令碼語言，由於先學的Python，對動態語言的特點比較熟悉，看到PHP後覺得和Python很類似，有種親近感。這可能是由於我在比較好的時機看到了PHP，PHP4好像是不支援物件導向的，而我看到的PHP已經到5.2了，全面開始支援物件導向；並且PHP本身就是為Web設計的，你都不能像Python一樣單獨寫個能脫離Web獨立啟動並執行程式（也許可以，我沒具體研究），對Web的支援應該相當好，懷著對PHP的好奇我進行了PHP的學習。

具體的部署從網上很容易得到，我的實驗環境是PHP5.2+Apache2+MySQL。

PHP學起來是很快的，學語言我有經驗，一般情況都是從上到下，再從下到上。從上到下是說，先總體瞭解語言本身，具有什麼樣的品質、特點；我們拿它能做什麼，不能做什麼，合適做什麼；是物件導向還是面向過程；應用的是否廣泛；成功的案例有哪些。只有對總體特性瞭解後才能決定我們到底學不學，才能清楚如果要學，憑我現在的經驗基礎用多長時間、什麼樣的方式來學。

從下到上是說，在具體學習一門語言的時候，先學習語言本身的文法結構。只要有其他語言的基礎，這個往往很簡單，無非是變數、常量、運算式、流程式控制制、函數、類、繼承、對象、記憶體管理。我學習PHP只用了兩小時，編了幾個小程式進行測試後就基本搞定了。

掌握了基本文法後，再學習語言的核心：類庫、架構。不同的語言預設帶的類庫是不同的，有的多有的少。Python就很多，PHP也不少，Java、.net非常全。類庫、架構才是一個語言的精華，掌握了語言常用的架構才算掌握了語言本身。當然，語言的學習最好和實際應用結合起來，可以一邊學一邊用，這樣學習的更紮實，速度也更快。

學習的時候最好能多看別人寫的代碼，每種語言都不乏很好的教程和代碼執行個體，盡量利用網路資源。

4.2. PHP開發工具

還有最後一點，學習一門語言必須要選擇得力的開發工具，不然你的開發效率是上不去的。Java就用Eclipse、JBuilder，.net用Visual Studio，Python用ActivePython的PythonWin，PHP呢？PHP就得用Zend，但Zend是收費的並且還很貴，看情況了，允許就用Zend，不允許就用EditPlus，PHPDev等。

4.3. PHP應用

PHP能直接嵌入到Html中，用法和ASP差不多。也就是_COOKIE，_SESSION，_REQUEST，這給動態網頁開發提供了很方便的特性，我覺得這基本上就夠用了，但實際工作時你必須考慮分工問題，也就說說把程式員和美工的工作分開，程式員專註於BussinessLogic，美工負責頁面設計，但頁面中要展示邏輯處理後的結果，這就涉及到怎麼樣把處理的結果告訴給Html。按道理說用PHP處理的HTML是可以直接嵌入PHP代碼的，我們只需把邏輯處理的代碼單獨放在一個檔案中就可以了，HTML包含此檔案，然後用輸出的變數結果就完了。但人總是很聰明的，早就看到了這個問題，因而好多人就紛紛提出Web的MVC架構，支援PHP的MVC架構也很多。只要用架構你就得熟悉這個架構，這無疑有增加了我們的學習成本。下面就說說我看過的幾個架構。

模版架構Smarty：當然還有其他的模版架構，而Smarty用的較多，下載了一個實際例子：ecshop就是基於Smarty；還有bBlog也基於Smarty。Smarty本身很複雜，但對我們來說就幾個常用的功能。Smarty提供了一種模版語言，讓HTML設計人員不用懂PHP就可以用PHP處理的結果，他規定了一套標籤，只要在HTML中用嵌入Smarty的標籤而不用嵌入PHP代碼就可以了，這為HTML設計人員帶來了方便，不需要學習PHP只需掌握幾個標籤就好了。

但Smarty標籤嵌入HTML後，HTML設計人員如果在開發工具如Dreamwaver（DW）中開啟HTML的話，看起來就是亂糟糟的一片了，違背了所見即所得 (WYSIWYG)的原則，這時可以下載DW的一個Smarty外掛程式來部分解決這個問題。

Smarty除了這個討厭的問題外還有很多好的地方，比如可以自動管理頁面Cache；可以讓使用者自己訂製顯示模板；安全性，防止嵌入的標籤對整個程式的傷害；速度據說也相當快，和直接用PHP差不了多少。

Smarty缺點是既然作為一個模板架構我們在開發的時候就要遵守它的規則，在編寫邏輯的時候，要不停的assign，assign，assign，但這也算清晰，我們也划得來。結論是：模板架構Smarty是值得選擇的。

但也有其他的選擇，很好玩的是下面兩篇文章，你可以細細品味一下：

超越模板引擎，PHP資源模板——模板終結者

 

PHP還有其他的Web架構象PHPMVC，ZendFramework，FleaPHP等，這些架構只是實現目標的一種途徑，我倒是認為能不用架構最好不用，PHP本身的特色就是輕快，PHP+顯示模版的方式已經夠了，用最簡單明了的方式完成工作不是更好嗎？

值得注意的是，不用架構不等於不用程式碼程式庫，千萬不能否認PHP成熟程式碼程式庫的作用，這在PHP裡叫PEAR（PHP Extension and Application Repository：PHP擴充與應用庫），可參考《用Pear加速PHP程式開發》。

4.4. 結論

最後得出結論：用PHP進行Web開發是首選，開發不採用現有MVC架構，採用PHP+顯示模版的方式，快速乾淨的開發應用。

5. 總結

上面對幾種常用的Web程式設計語言進行了比較，分析的立足點是我自己的需要，也許能代表一部分朋友的情形吧。

應用於公司開發獨立的資訊化產品、或其他產品（如硬體裝置）的輔助軟體產品。

不同的應用選擇不同的技術，希望和大家進行探討。

===============================================

轉自：http://blog.csdn.net/kernelspirit/archive/2006/12/22/1453230.aspx