目錄
緣起
隨著互聯網近年來的迅猛發展，尤其是單頁面Web應用（Single Page Web Application）以及Node.js的興起，使得客戶端和服務器端的界限越來越模糊了。
客戶端從原來僅僅是展示頁面和簡單的校驗邏輯轉變為一個擁有完全狀態的由JavaScript驅動的應用程序。
服務器端從原來的All-In-One（取數據，執行業務邏輯，渲染頁面）到僅僅負責取數據和執行業務邏輯的無狀態的Restful Service Provider。
未來的企業級應用的架構的方向以及技術實現可能會有非常大的改變，這個系列文章是我對于Java企業級應用現狀的理解以及未來的展望。
把渲染頁面的功能從服務器端剝離出來之后，帶來的以下主要的優勢
- 服務器端無需保存任何客戶端的狀態從而使得Cluster變得平凡，提升了服務器的處理容量
- 一個服務器端的實現能夠支撐不同類型的客戶端比如瀏覽器，IOS，Android
- 使得切換服務器端技術棧的成本降低，原先所有的頁面都可以復用。比如我有legacy的Java系統有非常復雜的功能，我新的系統想用其它平臺開發比如Node.js，我不會損失任何東西，原先的Java系統的接口都可以調用。如果按照以前的做法，整個頁面都是用JSP或者JSF開發，那么基本上只有推倒重來了
- 開發頁面的和開發服務器端的可以并行進行，互不干擾
- 使得在頁面中寫SQL和寫業務邏輯變得不可能，一些老的Java系統經常有人圖省事，把SQL直接寫在JSP里面
開發人員和管理人員的困惑
在一次和項目內部開發人員的交流的過程中，我介紹了這個思路，不出所料的，得到了很多問題，比如
- JavaScript作為一個弱類型語言，能夠支撐大的代碼量嗎？
- JavaScript沒有Eclipse，沒有自動完成，叫我怎么寫代碼？
- 聽說Twitter已經從Client Side渲染轉向Server Side渲染了，是不是說還是Server Side渲染性能好？
- 聽說FaceBook已經在手機上放棄HTML5了，是不是出了什么狀況？
- 公司已經在JSF上投入了這么多了精力，難道要放棄？
- 停止搗鼓新玩意，都是沒有經過考驗的東西，放在生產上能行嗎？
我認為這些都是很好的問題，而且都不是一兩句話能夠說清楚的。有一點是確定的，人都是不太愿意改變的，尤其是自己已經非常熟悉的東西。我個人也是這樣走過來的，再認識到這些之前，我用過JSF，Vaddin等等Server Driven的框架，當時由于我的背景以及當時項目的緊迫性，沒有足夠的能力來做完整的評估。后來慢慢的在項目發展中，碰到了種種困難，現在看來，雖然說當時的選擇從現在來看是錯誤的，但是正是因為有失敗才讓我有動力去尋找正確的東西，正當我毫無頭緒的時候，AngularJS進入了我的視線
AngularJS
在接觸這個框架之前，我一直認為JavaScript只是個玩具語言，在加上網上各種對于這門語言的口誅筆伐，我一直對于它嗤之以鼻。但是在深入了解AngularJS之外，我徹底改變了想法。Module、Directive、Data Binding等等，直到現在，我仍然不能忘記當初的驚喜。
如果說AngularJS讓我有了前面所說的思路，那么更為重要的是，它為我打開了更加精彩的Node世界的大門。沒有了語言的障礙，Node很自然的成為了我今年最為重要學習主題之一。
Java企業應用的問題
如果說AngularJS完成了客戶端問題，那么我們仍然需要一種方法來解決服務器開發效率和端性能問題。在這個方面，以Spring為主的主流框架幾乎已經壟斷了企業級應用的開發。如果你去問一個Java開發人員，也許5年前和現在相比沒有本質的區別。如果說Java企業應用最大的優勢是什么，很多架構師都會告訴你有非常成熟的框架和架構，而且Java語言就像普通話，外面到招人很好招，照此說來，Java解決方案就一點問題也沒有了嗎？
肯定不是?。?！Java現有架構最大的問題就是，雖然Java是一個完全OO面向對象的語言，但是我們開發過程卻只把它當作是過程式語言來用?。?！你一定會問這是為什么呢？那請你看看你的代碼，你的所有的POJO只是用來作為Hibernate Annotation的載體而已，而所有的業務邏輯都在所謂的Service類和Dao類中，那些類都是由一堆方法構成的，所有的這些其實都是與所謂的OO設計背道而馳的。
但是OO真的是解決問題的銀彈嗎，答案還是否定的。OO用來建模一個小范圍的概念沒有問題，但是如果想要用來描述現實世界中真正復雜的業務就有點力不從心了。想著過去多少次大家為模型應該是什么樣子來爭論不休，到頭來誰也說服不了誰，我們都在尋找完美的模型，但是不幸的是，這樣的模型要么不存在，要么就過于復雜，導致一般人無法理解。
另外舉一個簡單例子，每個稍微用過Spring都知道Dependency Injection，依賴反轉，但是即使是很資深的開發人員仍然從來沒有用過構造函數注入。
Java應用到最后都趨向一個大一統的野獸，大家回想一下，有多少次，因為一個無關緊要的Service配置問題，導致整個Web應用啟動不了。有多少次你修改了一個函數甚至頁面，結果要求完全重啟JVM，要花個幾分鐘的時間重啟Tomcat。
有多少次上面管理人員讓你寫單元測試，然后你發現，要寫一個單元測試，必須加載整個Spring環境，跑一個單元測試要花幾分鐘時間等Spring幫你初始化好一大堆無關緊要的beans。到頭來，你不得不放棄，因為寫一個單元測試的成本太高了。
