RoR的正確定位

lgx522發表於2007-04-26
最近由於工作原因，用appfuse、asp做了些東西，猛然間又懷念起四個月前學習的RoR，這才領悟到了RoR正確的定位。

自從RoR開始流行以來，一直就口水戰不斷。原因何在？其實就在於不知道國外大佬們作何感想，一上來就把RoR的矛頭指向了Java。Java是大家熱愛了很久的老大，MS炒了好幾年的C都動彈不了它，說明其在穩定性、規範化、應用範圍上是具有統治力的。RoR本身是相當優秀的，可惜指錯了矛頭，反倒搞得四處樹敵，難以推廣。
筆者在幾個月前接觸RoR的時候，有個大體模糊的感覺，認為它應當是asp、php的勁敵，經過這幾個月的實踐，更加堅定了這種想法。

RoR為何會在J2EE程式設計師這個群體中火熱起來，甚至讓很多人倒戈？原因就在於大家吃夠了J2EE的苦頭。扔掉了分散式的EJB後，大家擁抱Spring，而Spring+XX+XX+XX的模式也還是太複雜了。它們的複雜，就在面對的是真正的企業級開發，要考慮太多、太遠，穩定性、高效能、擴充套件性、異構系統整合、遺留系統重用、多種客房端等等，全是一堆頭讓人頭疼的事情。需求如此複雜，技術架構自然就複雜了。而國內大多數吃J2EE這口飯的，90%的情況下所面對的，都是Johnson所說的那90%的簡單問題，說白了，就是用Web+DB就可以解決的問題。而這種場景下，RoR是當前最好的OOP解決方案。

RoR與ASP、PHP一樣，都是為Web+DB量身訂做的。在這個領域，動態指令碼語言有絕對的優勢。
JSP剛開始跟ASP、PHP在internet領域鬧騰了好幾年，結果還是幹不過簡單的後兩者。時至今日，MS的“棄兒”ASP在國內的網站仍佔統治地位、PHP則在歐美一路領跑。這緣於internate領域業務的快速變化性，那些編譯來配置去來回折騰的技術實在浪費了程式設計師太多的時間精力。這些快速變更的東西，我們要的是用editplus修改之後，瀏覽器刷一下就可以看到結果。在這個領域，我們不需考慮那麼多複雜的事件，我們要的是簡單快速。所以即使如ASP.NET封裝得那麼好的tag，到頭來還是不如HTML嵌程式碼好使。
所以在Internet領域，我們需要的還是動態指令碼。

作為J2EE程式設計師，我們歷經了多少探索和磨難，好不容易習慣了OOP，習慣了ORM，習慣了MVC。走盡萬水千山路之後，當我們發覺做Web+DB竟然不如當初甩到一邊的ASP、PHP時，真是無比沮喪。那是否意味著我們要回到ASP、PHP或者純JSP呢？答案自然是否定的，因為RoR出現了。
它可以讓習慣了OOP、ORM、MVC的我們繼續寶貴的設計思想，以不低於ASP、PHP的效率開發出結構合理、統一規範的Web+DB，這正是RoR的可貴之處。
唯一令人遺憾的是，我們又必須學習一門語言了，而且是小日本搞出來的Ruby。一門語言入門容易，精通則難。想當初弟兄們不知費了多少寶貴的日日夜夜才把Java練純熟啊。不過想想那幫費力氣練熟了VB、VC、ASP、WinForm的MS同行們吧，它們不是更慘，不但語法變了，連設計思想都變了，MS太不厚道！相對起來，Java時至今日仍保持良好的相容性和技術延續性，就憑這一點，我們也應該繼續支援Java。同時，為了在近兩三年內（Groovy和Grails真正成熟起來）不讓那90%的Web+DB繼續痛苦，我們的確應該暫時用RoR來幫幫忙了。

近日終於想明白了這一點，在此與各位共享。
願各位弟兄們早日用RoR搞出幾個像樣的CMS、Forum、Blog、Eshop、Email這類俗氣但廣泛應用的東西，併成功發展出一片價廉物美的RoR主機空間。這樣的話，RoR一定可以走出現在這種叫好不叫座的局面。
至於原先真正的“企業級應用”，還是繼續發揚靜態編譯語言的優勢，好好站穩Java的腳，免得被MS趁亂了奪了去，那樣的話，將是整個開源領域的災難。

[該貼被lgx522於2007年04月26日 18:15修改過]

相關文章