rails電子商務

① 范凱的個人觀點

來自范凱的個人博客 因為看到一篇討論PHP，Python和Ruby的編程語言討論貼，就說說我的PHP，Python和Ruby之路吧：
我2000-2001年用PHP用了兩年，那還是第一次互聯網泡沫時期，到2001年後期，Servlet/JSP流行，然後我就發現：你說用PHP寫的東西，都會被人鄙視。當時我們其實也用Java了，只不過用Java寫後端的消息隊列。
2001年後期泡沫破滅，我跑去做企業應用，就主要寫Java寫了很多年，中間2003年開始做JavaEye網站，到2006年用Rails重寫JavaEye之前的3年，用的是phpbb搭建的，所以PHP也斷斷續續一直用到了2006年。
以我2000-2006年總共六年多的使用體驗來說，我對PHP真的是深惡痛絕之，但凡做一個稍微大一點的系統，代碼就很容易失控。2002年以後，我曾經一度以為PHP這個東西快死掉了，那個時候大家都言必稱J2EE和.net了。結果Web2.0之風襲來，大家又發現J2EE太重，PHP又死灰復燃了，我其實很詫異現在PHP居然又變得如此流行。從技術上來講，PHP是個很爛的東西，但它門檻低，易部署，普及率高，好找人，實在是互聯網時代的VB，打不死的小強。
Python我大概是04-05年迷戀了一年左右，研究過Zope，plone，後來還看過wxPython，曾經一度想用Python寫JavaEye網站。記得04年Rails出來之後，還很長一段時間被我深深鄙視過。
但後來我去杭州拜訪potian，被他的Rails實踐經驗說服了，之後我和他以及其他人在JavaEye上面有一個很長的討論貼，討論Rails的運行機制，最後我又被他說服了。然後我還不死心，研究和比較了Rails和Django，不得不死心了，後來還曾經幾次想用Python，每次都死心的很徹底，現在就徹底不考慮Python了。
就算你不用Rails，作為一個程序員，我也強烈建議你學習一下Ruby，僅僅因為可以開拓你的思維就很值得了。因為Ruby的語法很強大很好玩，是現代語言版本的smalltalk，算是很原汁原味的面向對象編程語言，你學習了Ruby以後，你就會發現，原來Java/C++所謂的面向對象就是TMD的山寨版本的面向對象，原來面向對象還可以這樣玩阿。
PHP用一句話來總結就是：quick and dirty
Python用一句話來總結就是：quick and clean,but not convenient for web development
Ruby用一句話來總結就是：code for fun and quick for web
補充一下吧：為什麼我當初用Rails來寫JavaEye網站：
在選擇用什麼工具開發JavaEye網站的時候，唯一的指導標准就是：用最少的人力，最少的時間開發JavaEye網站，並且後期維護和持續升級，乃至重寫的時候，代價最小。
首先排除Java和C#，代碼太多太麻煩；
其次排除PHP，項目一大，代碼一多，代碼的管理很成問題，PHP缺乏一個起碼的包管理機制；
當時重點考察Python和Ruby，因為有豆瓣的先例，開始很傾向於Python，而且我那個時候對Python比較熟悉，還曾經痴迷過一段時間的wxPython，對Zope和plone也有一些研究。
但後來比較了Rails和Django之後，就傾向於Rails了，差距實在太大了，而且當時Django很不成熟，在很早期的版本。其實即便現在Django和Rails的差距也沒有縮小過。
但讓我最終下定決心的是potian在05年就大規模使用Rails的實際工程經驗，我曾經去杭州就我比較質疑的問題當面請教過他，和他談過以後，就決定用Rails了。
應該說，我當初用Rails的決定很英明！ 在四年以前，當我開始鼓吹Hibernate，抨擊EJB的時候，遭到的是群起而攻之的場面，但是不到一年之後，Hibernate已然得到了普及和大多數Java開發人員的認可；
在三年以前，當我開始贊譽spring的時候，spring還面臨著EJB3的陰影，以及EJB2對其不登大雅之堂的指責，然而不到一年的時間，spring已經成為絕大多數Java開發人員的首選；
在兩年以前，我極力希望宣傳webwork，唱衰JSF，時至今日，webwork以Struts2.0的身份容登大雅之堂，而JSF還在靠廠商死挺著；
而當一年之前我開始採用RoR開發JavaEye的時候，RoR的置疑之聲還甚囂塵上，但當我在今年初預言07年下半年RoR在國內會被廣泛接受的時候，很多人已經笑不出來了；
今年我預言些什麼呢？我覺得會是AJAX技術走出PC的時代，證據就是iphone，與此相關聯的事情就是REST架構的流行。
但是這篇文章裡面我想談的卻不是我預言的水平準不準，而是想談Java真的會因為RoR的流行而過時嗎？目前在web開發主要應用在兩個大的領域，互聯網和企業應用，我們分別來看一下：
一、互聯網領域
互聯網領域第一大動態語言是PHP，第二第三分別是ASP和Java。在中小型互聯網應用當中，PHP的王者地位不容動搖，但在大型應用當中，Java是目前主流的選擇，特別是電子商務類型的應用，例如阿里巴巴就從早期的PHP轉變到Java，從前的eachnet也是如此。造成這樣局面不是沒有原因的：
1．中小型互聯網網站強調開發速度，維護成本，以及入門快速和部署成本，PHP是最合適的選擇；用Java則顯得過於笨拙，開發慢，維護成本高，入門周期長，部署麻煩；RoR開發速度最快，維護成本最低，但是RoR入門速度沒有PHP快，部署成本比PHP高。因此中小型互聯網網站主流還是PHP，但RoR能夠占據一定的份額。
2．大中型互聯網站強調穩定性，性能，大規模代碼的組織能力，而開發效率則退居次要地位，有些應用如電子商務對事務有很高的要求，顯然Java是最合適的選擇；PHP的代碼組織能力最差，RoR次之。
在互聯網領域，Java從來就不是主流，並且Java的適用領域和RoR不太重合。我們甚至可以這樣說，RoR現在在互聯網領域取代的是那些原本不適合用Java，但是被錯誤的選擇了Java的項目。
二、企業應用領域
目前企業應用領域第一大語言是Java，dotnet其次。企業應用採用的技術和行業有很大關系：例如金融行業，電子政務行業一般只採用Java。dotnet發展了6年尚且沒有進入企業高端的應用，RoR在短期之內也很難取代Java的地位。
在企業應用領域，Java是主流，並且Java的適用領域和RoR也不太重合。我們也可以這樣說，RoR將來在企業應用領域要取代的是那些原本不適合用Java，但是被錯誤的選擇了Java的項目。
至此，我想Java程序員大可以松一口氣，RoR目前有哪些不適合的場合呢：
1．對事務要求非常高的場合
RoR還是很簡單的單資料庫事務控制，缺乏精細的事務控制功能，當然也不支持跨資料庫的分布式事務。因此對於事務要求嚴格的大型電子商務網站，部署復雜的分布式資料庫場景顯得力不從心。當然也許有些plugin可以提供這些功能，但是從目前的功能完備性和成熟度來看，還不夠。
2．處理大量遺留資料庫的場合
ActiveRecord的威力很大程度上來自約定，大量命名糟糕的遺留資料庫會對RoR造成比較大的障礙。
3．龐大的項目團隊，對開發速度要求低的場合
例如日本外包項目，團隊龐大，個體開發速度要求低。但是對於代碼規范要求嚴格的項目。
雖然RoR不會取代Java，但不意味著作為程序員的你可以固步自封。即使在工作當中用不上RoR，多看一點新的技術，對於開闊個人視野也有很大的好處。 挺有意思的現象
記得過去還沒有創辦JavaEye的時候，在技術社區裡面推廣Hibernate(也算不上是推廣，只是和別人交流Hibernate)，就有一大批人酸酸的跳出來說，你們今天學習這個明天學習那個框架，全都是跟風，這些框架都是浮雲，真正JDBC這種基礎知識才是實力的，我就用JDBC，我用的一直很好，我完全沒有必要去學習Hibernate……
每當看到這種話，我就覺得特別好笑，用一個我發明的說法叫做「牛逼哄哄的露怯」。沒有人逼你學習Hibernate，你不樂意關心Hibernate，那就繼續用JDBC好了，這個世界從來都不是非黑即白的。
其實這種人的心態很有意思。他一方面眼紅人家學習新的技術，另一方面自己又不想花時間和代價去學習，所以恨不得所有的人都不要去學習新技術，這樣他心裡就感覺很安全了，正因為如此，他就總是要時不時跳出來打擊一下別人，表面上很牛逼，其實虛弱的內心掙扎一覽無余。
如果想把技術作為終身職業，那麼對於技術人員的起碼要求就是不能固步自封，要始終以開放的心態接受新技術。
打好基礎知識固然重要(重要到根本無需你一遍又一遍的祥林嫂)，但是不接觸新技術，新思路，新的理念，很快就會被淘汰掉。
當然學習新技術也不是盲目的什麼都學習，什麼流行學習什麼，而是根據自身的需要，有選擇的學習。例如Java Web框架有很多很流行的，Struts，Webwork，Spring MVC，Tapestry，JSF，主流的就有5個，盲目的學習者就是人家說什麼他就學什麼了。而聰明的學習者應該對這些東西都去接觸一下，從中選擇一個值得自己投資時間成本去學習的框架。例如對這五個框架我都涉獵過一遍，最終我把時間花在了Webwork上面，事實也證明我當初的投資是正確的。
我學習ruby on rails有很現實的需要，其實即便拋開現實的需要，我也認為如果有空，Java開發人員有必要學習一下，原因是：
1、ruby語言和rails框架的社區力量正在以驚人的速度增長，甚至已經進入爆炸式繁榮的前夜，這不是曇花一現的現象，而是一個時代開始的象徵。
2．從我這段時間學習的情況來看，ruby語言有足夠的學習深度，我原來以為自己一個很快速的上手，然後就很精通了，但是ruby不像PHP那種方便麵，其知識的廣度和深度都讓我感覺這是一個完整的知識體系。也正因為如此，ruby生命力會很長。
3． ruby和rails是非常非常Unix-like的東西，經常和操作系統提供的功能有深度的依賴，這和Java這種不依賴操作系統，什麼基礎設施都自己捲起袖子自己創造的理念相比，非常非常的不同。這樣做會帶來一個很大的好處，很多在Java裡面解決方案很復雜的問題，在ruby方案中就很簡單可以搞定，相比之下，讓Java顯得頗為大而無當。
不過ruby和rails也樹立起了一堵牆，這堵牆就是Unix操作系統，要學好我，你就先跨越Unix這堵牆吧。呵呵，這也是為什麼rails core team清一色的MacOSX的原因了。
不過我覺得這是好事，我本人是Unix fans，樂意見到這種現象，況且憑借我多年深厚的Unix功底，在ruby fans中，我又站在了一個很高的起點上領跑了。
想學好ruby嗎？先在你的電腦上面安裝MacOSX/ubuntu作為開發環境咯。 孟岩最近寫了一篇博客：
Ruby 1.9不會殺死Python
這篇文章很有點標題黨的意思，所以在JavaEye論壇很快被水掉了，只好鎖貼：
但我個人對於孟岩的觀點是不敢苟同的。首先我並不同意所謂魔幻語言和簡約語言的分類。其實Martin Flower論述過這個問題，他是用「人性化介面」和「最小介面」來區分編程語言的風格化差異的。
其實不用我多說，Martin論述的挺充分了。強把Ruby和C++歸為魔幻一類，其實並不準確，因為Ruby的魔幻語法和C++相比，最大區別在於：
C++的魔幻語法會導致代碼的可讀性變差，而Ruby的魔幻語法會導致代碼的可讀性大大提高。
不論是matz本人，還是整個Ruby社區，Rails社區諸多開源項目的作者，抑或整個Ruby和Rails開發者社區，在一個編程哲學問題上是高度統一的，這就是：
強調程序員的快樂編程，追求人性化編程，在代碼的可讀性上面有偏執的追求，拒絕難以閱讀的代碼和難用的API。也就是所謂的coding for fun!
所以你看無論是Rails，rake，rspec，甚至移植自lucene的ferret，都鮮明的體現出來這種特點，就是API簡單好用，讓你寫的代碼像英文文章，自然流暢，輕松愉快。要是哪個Ruby框架的API復雜晦澀，在Ruby社區簡直沒法混，大家根本不買他的帳，這也是為什麼Ruby應用於DSL領域這么熱的根本原因。
對於ruby程序員來說，這種追求編程人性化的哲學理念會潛移默化影響程序員，讓他不知不覺把代碼的可讀性越寫越好。對於程序員來說，誰不想coding for fun呢？ 而當你品嘗到了coding for fun的樂趣，又怎麼會輕易拋棄？
所以Ruby受程序員歡迎的根本原因還是在於它是一種能給你帶來編程樂趣的語言。 有人說，robbin你說了那麼多RoR的優點，你啥時候說說RoR的缺點阿？你說的缺點肯定比別人說的更客觀。沒辦法，為了表現出來我不是一個RoR粉，只好總結點缺點，以饗RoR黑子們：
Ruby和Rails的一些缺點的總結：
ruby的問題我覺得主要是：
1．ruby本身的性能是比較差的，無法直接做一些計算密集型的任務
比方說大量的分詞運算、語料訓練什麼的，用ruby寫是不行的
2．ruby的C擴展很難寫
正因為ruby性能差，所以很多情況下要依賴C寫的底層庫，但是寫ruby的擴展C庫是很困難的事情。一方面沒有特別多的資料介紹，你能參考的只有《Ruby Hacking Guide》，另外一方面Ruby是帶有GC的語言，C又是沒有GC的，所以如果你對ruby的GC機制沒有特別清楚的了解情況下，寫C擴展會出現意想不到的問題：比方說你寫的程序邏輯沒有任何問題，但是和ruby配合起來就會不定期的出現錯誤，這就是你C程序的某個賦值變數可能會被ruby GC以你意想不到的方式銷毀。
3．ruby的C擴展庫質量不高，容易出現內存泄漏問題
正因為上面的原因，很多第三方的C擴展庫質量不好，很容易出現內存泄漏問題，這是一個很頭疼的問題，你很難定位，也很難解決，只能盡量避免使用第三方擴展C庫。
Rails的問題我覺得主要是：
1．特別容易出現命名沖突
你自己寫的代碼裡面給類增加的方法，動不動就和Rails給類擴展的方法名稱沖突了。這種錯誤很隱蔽，很難發現。這也是ruby語言動態性帶來的一個負面影響
2．Rails每次升級API變動都比較大
Rails升級是不太考慮向下兼容性的，所以每次升級的話，可能你很多代碼都要改，更糟糕的是很多Rails插件特別喜歡以hack rails的方式來擴展Rails功能，那麼Rails一升級，插件的兼容性幾乎肯定是不行的，這個是比較痛苦的事情。
3．Rails的view方面還是比較原始的erb拼接字元串方式，像JSP那樣原始，沒有一個類似Java的velocity/freemarker那樣的頁面模版庫，所以寫helper動不動要用字元串去拼html片斷，如果是特別復雜的view需要拼的話，代碼就會寫的很醜陋。
當然總體來說，RoR還是讓我感覺非常滿意的，特別適合互聯網應用。 從無到有剛開始做一個網站或者一個產品，要非常聚焦，沒有旁的多餘功能，只有一個做的極其牛X的核心功能，牛X到別人沒有辦法模仿你，於是網站開始嶄露頭角；
等核心功能成功以後，網站開始聲名鵲起，為了擴展用戶規模，產品開始多元化，各種各樣時髦功能，各種各樣用戶要求的功能紛紛上馬，於是用戶規模開始快速擴張；
等用戶規模已經起來之後，開始聚焦商業目標，於是刪繁就簡，開始砍掉與商業目標不符合的枝節功能，加強和商業目標符合的核心功能，網站進入健康的商業循環；
大部分網站都可以做到第一個階段，但其中大部分都會倒在第二個階段，而邁過第二階段能夠做到第三個階段的就鳳毛麟角了。到了第三個階段，一個產品才真正開始成熟起來，才具有頑強的生命力，在IT垂直領域裡面，JavaEye處於第二個階段，需要向第三個階段轉變。
也曾經盲目的想把JavaEye的規模做到行業最大，於是上了各種各樣的產品和功能，很多都沒有細化和雕琢，現在想來都有些多餘，而符合商業目標的核心功能又用力不足。現在總算想明白一個道理：規模最大又如何？還是不賺錢。所以接下來怎麼做就很清楚了。
另外一條思路是做平台，互聯網的未來生態系統肯定是由平台和內容提供商構成的，你要麼做平台，要麼做內容提供商。但在IT垂直領域，用戶規模和市場空間過於狹小，平台沒有足夠的空間生存，所以這條路不通。不要企圖做大而全的門戶，不要企圖做無所不包的平台。
定位好目標，不要做無關的功能，突出符合商業目標的核心功能和產品，足矣！

② php,jsp,asp三者優缺點...

JSP ASP PHP
運行速度 快 較快 較快
運行耗損 較小 較大 較大
難易程度 容易掌握 簡單 簡單
運行平台 絕大部分平台均可 Windows平台 Windows/UNIX平台
擴展性 好 較好 較差
安全性 好 較差 好
函數性 多 較少 多
資料庫支持 多 多 多
廠商支持 多 較少 較多
對XML的支持 支持 不支持 支持
對組件的支持 支持 支持 不支持
對分布式處理的支持 支持 支持 不支持
應用程序 較廣 較廣 較廣
----------------------------------------------------
轉載:
慢慢看吧!
ASP、JSP與PHP的比較

目前，最常用的三種動態網頁語言有ASP(Active Server Pages),JSP(Java Server Pages),
PHP (Hypertext Preprocessor)。

簡 介

ASP全名Active Server Pages，是一個WEB伺服器端的開發環境， 利用它可以產生和運
行動態的、交互的、高性能的WEB服務應用程序。ASP採用腳本語言VB Script（Java script
）作為自己的開發語言。

PHP是一種跨平台的伺服器端的嵌入式腳本語言. 它大量地借用C,Java和Perl語言的語法
, 並耦合PHP自己的特性,使WEB開發者能夠快速地寫出動態生成頁面.它支持目前絕大多數數
據庫。還有一點，PHP是完全免費的，不用花錢，你可以從PHP官方站點(
t)自由下載。而且你可以不受限制地獲得源碼，甚至可以從中加進你自己需要的特色。

JSP 是Sun公司推出的新一代站點開發語言，他完全解決了目前ASP,PHP的一個通病－－
腳本級執行（據說PHP4 也已經在Zend 的支持下，實現編譯運行）.Sun 公司藉助自己在Jav
a 上的不凡造詣，將Java 從Java 應用程序 和 Java Applet 之外，又有新的碩果，就是Js
p－－Java Server Page。Jsp 可以在Serverlet和JavaBean的支持下，完成功能強大的站點
程序。

三者都提供在 HTML 代碼中混合某種程序代碼、由語言引擎解釋執行程序代碼的能力。
但JSP代碼被編譯成 Servlet 並由 Java 虛擬機解釋執行，這種編譯操作僅在對 JSP 頁面的
第一次請求時發生。在 ASP 、PHP、JSP 環境下， HTML 代碼主要負責描述信息的顯示樣式
，而程序代碼則用來描述處理邏輯。普通的 HTML 頁面只依賴於 Web 伺服器，而 ASP 、PH
P、JSP 頁面需要附加的語言引擎分析和執行程序代碼。程序代碼的執行結果被重新嵌入到
HTML 代碼中，然後一起發送給瀏覽器。 ASP 、PHP、 JSP三者都是面向 Web 伺服器的技術
，客戶端瀏覽器不需要任何附加的軟體支持。

技術特點

ASP:

1. 使用 VBScript 、 JScript 等簡單易懂的腳本語言，結合 HTML 代碼，即可快速地完成
網站的應用程序。
2. 無須 compile 編譯，容易編寫，可在伺服器端直接執行。
3. 使用普通的文本編輯器，如 Windows 的記事本，即可進行編輯設計。
4. 與瀏覽器無關 (Browser Independence), 用戶端只要使用可執行 HTML 碼的瀏覽器，即
可瀏覽 Active Server Pages 所設計的網頁內容。 Active Server Pages 所使用的腳本語
言 (VBScript 、 Jscript) 均在 WEB 伺服器端執行，用戶端的瀏覽器不需要能夠執行這些
腳本語言。
5.Active Server Pages 能與任何 ActiveX scripting 語言相容。除了可使用 VBScript
或 JScript 語言來設計外，還通過 plug－in 的方式，使用由第三方所提供的其他腳本語言
，譬如 REXX 、 Perl 、 Tcl 等。腳本引擎是處理腳本程序的 COM(Component Object Mod
el) 物件。
6. 可使用伺服器端的腳本來產生客戶端的腳本。
7.ActiveX Server Components(ActiveX 伺服器元件 ) 具有無限可擴充性。可以使用 Vi
sual Basic 、 Java 、 Visual C＋＋ 、 COBOL 等編程語言來編寫你所需要的ActiveX Se
rver Component 。

PHP:

1．資料庫連接
PHP可以編譯成具有與許多資料庫相連接的函數。PHP與MySQL是現在絕佳的組合。你還可
以自己編寫外圍的函數取間接存取資料庫。通過這樣的途徑當你更換使用的資料庫時，可以
輕松地更改編碼以適應這樣的變。PHPLIB就是最常用的可以提供一般事務需要的一系列基庫
。但PHP提供的資料庫介面支持彼此不統一，比如對Oracle, MySQL， Sybase的介面，彼此
都不一樣。這也是PHP的一個弱點。
2．面向對象編程
PHP提供了類和對象。基於web的編程工作非常需要面向對象編程能力。PHP支持構造器、
提取類等。

JSP:

1．將內容的生成和顯示進行分離
使用JSP技術，Web頁面開發人員可以使用HTML或者XML標識來設計和格式化最終頁面。使
用JSP標識或者小腳本來生成頁面上的動態內容。生成內容的邏輯被封裝在標識和JavaBeans
組件中，並且捆綁在小腳本中，所有的腳本在伺服器端運行。如果核心邏輯被封裝在標識和
Beans中，那麼其他人，如Web管理人員和頁面設計者，能夠編輯和使用JSP頁面，而不影響內
容的生成。
在伺服器端，JSP引擎解釋JSP標識和小腳本，生成所請求的內容（例如，通過訪問Java
Beans組件，使用JDBCTM技術訪問資料庫，或者包含文件），並且將結果以HTML（或者XML）
頁面的形式發送回瀏覽器。這有助於作者保護自己的代碼，而又保證任何基於HTML的Web瀏覽
器的完全可用性。
2．強調可重用的組件
絕大多數JSP頁面依賴於可重用的，跨平台的組件（JavaBeans或者Enterprise JavaBea
nsTM組件）來執行應用程序所要求的更為復雜的處理。開發人員能夠共享和交換執行普通操
作的組件，或者使得這些組件為更多的使用者或者客戶團體所使用。基於組件的方法加速了
總體開發過程，並且使得各種組織在他們現有的技能和優化結果的開發努力中得到平衡。
3．採用標識簡化頁面開發
Web頁面開發人員不會都是熟悉腳本語言的編程人員。JavaServer Page技術封裝了許多
功能，這些功能是在易用的、與JSP相關的XML標識中進行動態內容生成所需要的。標準的JS
P標識能夠訪問和實例化JavaBeans組件，設置或者檢索組件屬性，下載Applet，以及執行用
其他方法更難於編碼和耗時的功能。
通過開發定製化標識庫，JSP技術是可以擴展的。今後，第三方開發人員和其他人員可以
為常用功能創建自己的標識庫。這使得Web頁面開發人員能夠使用熟悉的工具和如同標識一樣
的執行特定功能的構件來工作。
JSP技術很容易整合到多種應用體系結構中，以利用現存的工具和技巧，並且擴展到能夠
支持企業級的分布式應用。作為採用Java技術家族的一部分，以及Java 2（企業版體系結構
）的一個組成部分，JSP技術能夠支持高度復雜的基於Web的應用。
由於JSP頁面的內置腳本語言是基於Java編程語言的，而且所有的JSP頁面都被編譯成為
Java Servlet，JSP頁面就具有Java技術的所有好處，包括健壯的存儲管理和安全性。
作為Java平台的一部分，JSP擁有Java編程語言「一次編寫，各處運行」的特點。隨著越
來越多的供應商將JSP支持添加到他們的產品中，您可以使用自己所選擇的伺服器和工具，更
改工具或伺服器並不影響當前的應用。

應用范圍

ASP是Microsoft開發的動態網頁語言，也繼承了微軟產品的一貫傳統——只能運行於微軟
的伺服器產品,IIS (Internet Information Server) (windows NT)和PWS(Personal Web Se
rver)(windows 98)上。Unix下也有ChiliSoft的插件來支持ASP，但是ASP本身的功能有限，
必須通過ASP＋COM的組合來擴充，Unix下的COM實現起來非常困難。

PHP3可在Windows,Unix,Linux的Web伺服器上正常運行,還支持IIS,Apache等通用Web伺服器
,用戶更換平台時,無需變換PHP3代碼,可即拿即用.

JSP同PHP3類似，幾乎可以運行於所有平台。如Win NT,Linux,Unix. NT下IIS通過一個插
件，例如JRUN或者ServletExec，就能支持JSP。著名的Web伺服器Apache已經能夠支持JSP。
由於Apache廣泛應用在NT、Unix和Linux上，因此JSP有更廣泛的運行平台。雖然現在NT操作
系統佔了很大的市場份額，但是在伺服器方面Unix的優勢仍然很大，而新崛起的Linux更是來
勢不小。從一個平台移植到另外一個平台，JSP和JavaBean甚至不用重新編譯，因為Java位元組
碼都是標準的與平台無關的。

性能比較

有人做過試驗，對這三種語言分別做循環性能測試及存取Oracle資料庫測試。

在循環性能測試中，JSP只用了令人吃驚的四秒鍾就結束了20000＊20000的循環。而ASP
、PHP測試的是2000＊2000循環（少一個數量級），卻分別用了63秒和84秒。（參考PHPLIB）
。

資料庫測試中，三者分別對 Oracle 8 進行 1000 次 Insert,Update,Select,和Delete
： Jsp 需要 13 秒，Php 需要 69 秒，ASP則 需要 73 秒。

前景分析

目前在國內PHP與ASP應用最為廣泛。而JSP由於是一種較新的技術，國內採用的較少。但在
國外，JSP已經是比較流行的一種技術，尤其是電子商務類的網站，多採用JSP。
採用PHP的網站如新浪網（sina）、中國人（Chinaren）等,但由於PHP本身存在的一些缺
點，使得它不適合應用於大型電子商務站點，而更適合一些小型的商業站點。
首先，PHP缺乏規模支持。其次，缺乏多層結構支持。對於大負荷站點，解決方法只有一
個：分布計算。資料庫、應用邏輯層、表示邏輯層彼此分開，而且同層也可以根據流量分開
，組成二維陣列。而PHP則缺乏這種支持。還有上面提到過的一點，PHP提供的資料庫介面支
持不統一，這就使得它不適合運用在電子商務中。
ASP和JSP則沒有以上缺陷，ASP可以通過Microsoft Windowsd的COM/DCOM獲得ActiveX規
模支持，通過DCOM和Transcation Server獲得結構支持；JSP可以通過SUN Java的Java Clas
s和EJB獲得規模支持，通過EJB/CORBA以及眾多廠商的Application Server獲得結構支持。

三者中，JSP應該是未來發展的趨勢。世界上一些大的電子商務解決方案提供商都採用J
SP/Servlet。比較出名的如IBM的E－business，它的核心是採用JSP/Servlet的WebSphere；
西方另外一個非常著名的電子商務軟體提供商，Intershop。它原來的產品Intershop1 2, 3
, 4占據了主要的電子商務軟體份額。它們都是通過CGI來提供支持 的。但去年10月後它推出
了Enfinity，一個採用JSP/Servlet的電子商務Application Server，而且聲言不再開發傳統
軟體。

總之
ASP，PHP,JSP三者都有相當數量的支持者，由此也可以看出三者各有所長。正在學習或
使用動態頁面的朋友可根據三者的特點選擇一種適合自己的語言。