Ameba 一個構建在J2EE標準之上的全棧框架，以后可能包含更多，從售前競標到發布部署整條流水。

前言

個人是比較懶的一個人，所以也懶得寫文檔，博客，但是我承認這是一個好習慣，記錄自己的成長和備忘。但是，身為程序員的我，還是把懶的精神發揮的有些淋漓盡致了，也不知道這個系列能持續多久，碎碎念多久。這個系列應該沒有什么技術性的東西，應該都是使用和設計上的。對于技術我還是比較狂熱的，但是，不等于每個人都有這種想法，而我試圖做的事情就是掩蓋這些技術，提供好用的接口，面向更多的程序員們，更加親民的框架。所以，這個框架不會有過多的彩頭，不會像很多國產框架那般小巧，而且因為是全棧式的，反而會很大，下面就會說這個問題，魚和熊掌的故事我們一會兒談談。既然寫了博文就是做好了接受“教育”的準備，所以呢，請大家暢所欲言（真的有人看的話，表示是一個毫無存在感的人）。目前框架還處于0.1.6的版本，還有很多特性沒有完善，或者這樣的需求不足以去實現。當然，我解決的都是幾年來我所遇到的問題，不一定適合任何人。框架的架構有一些大刀闊斧的變動，和我們現在所使用的層次結構出入比較大，可能一些人無法接受，但事實上，我們真的需要那么多層次，那么多接口么？在我的答案中是不需要的！快速穩定的版本迭代，要比接口設計更加重要，我們大多數時候一個接口對應一個實現，那么這樣的接口真的有存在的意義么？為并不存在的虛假需求預留接口真的有必要么？再者，面對RESTful的結構，不同的service實現有必要么？通過不同的URI尋找不同的實現才是最好的選擇吧？這部分應該由客戶端去控制，而我們所做的應該是對應用戶角色控制好權限邏輯，只要對不同service所提供的對外服務加入安全控制就足夠了，剩下的交給客戶端去選擇，這些年服務的操碎了心，應該適當的減輕工作了。

設計目標

框架從最開始的產生就是為了解決開發效率、項目管理、團隊協作和擴展問題，當今的終端過于繁多，產生了服務接口多次重構、更改或添加新接口供新終端使用的現象，所以，我需要一個可以對外提供服務接口，同時可以對外提供友好的UI界面直接提供給客戶的東西。就這樣，RESTful出現了，我固執的相信JAX-RS就是我想要的。我選擇了jersey作為基礎，那個時候jersey還是1.x，不支持對象的直接傳輸，bean的驗證，甚至過濾器還沒有完善。我整合了guice，利用AOP實現了對象到json字符串，form表單的轉換，bean的驗證，安全控制等等。在之后接手了別的項目就沒有搞下去。一年后，jersey升級到了2.x，這真的是一次革命性的升級，實現了我所需要的所有功能，內置的IoC，filter的完善等等，這真的是令人振奮的事情（說實話，oracle接手java之后有很多的變革發生，java不再那么的土鱉了）。然后我利用業余時間重寫了之前的框架，重新開始一個項目，就這樣Ameba產生了！我整合了HTTL，Ebean，實現了一些基礎的東西，包括靜態文件處理、Model的增強、一個配置文件等等，之后公司又忙了起來，到處“救火”，直到今天，中間又停滯了半年多。不過，前一段時間因為一些原因，我又開始利用業余時間去完善框架，向playframework看齊，將框架拆分出許多模塊，加入了開發模塊、詳細的錯誤信息提示、熱加載、事件系統、ebean升級到4.x（play還是2.3.x，前一段時間ebean的開發者和play的開發者還在討論ebean 4.x和play2的模塊化整合）、完善了模板與模板的自動尋找、簡單的模塊系統等等。

Ameba的目標是核心功能只提供RESTful+模板+ORM（必然，你也無法剝離其中的任何一項，但是可以禁用模板的特性，或者使用你自己的模板），其他功能全部采用模塊的形式插入進來，并且模塊是自我配置的，而主配置文件可以覆蓋任何模塊配置。這點和play略有不同，但是主旨基本一樣，不過我沒有想過要復制play，而是想要比play更好，play脫離了我們java程序員，比較傾向于scala，而且怎么高興怎么來，不會去管什么Java規范（標準）問題，而Ameba是親和J2EE規范的（雖然他是Java SE規范），建立在JAX-RS標準之上，對其進行擴充粘合，讓開發者也采用模塊的方式開發，并且不產生太多的額外學習成本。而目標和play也有很大出入，play更前向于敏捷開發，寫較少的代碼，還是在框架層面，而Ameba定位在流程上，從售前競標到上線部署，整個流程，當然Ameba也推崇敏捷開發。所以，Ameba的網會鋪的很大，實現點會很多，說實話我不確定是否能堅持下來。

關于大小、重量和第三方類庫

Ameba采用了jersey、logbak（groovy配置）、AKKA、Ebean等等第三方類庫，所以注定Ameba的身材很感人，足有40M+，這其中包括了一個NIO的服務器，和各種第三方工具。

較大的類庫有

1. groovy-all-2.3.4.jar 7.3M 用于配置logbak，對于groovy編寫配置文件真是大愛，不愿意割舍。
2. scala-library-2.10.4.jar 7.1M AKKA依賴的東西，play也會有這個，因為play用akka作為最基礎的架構
3. akka-actor_2.10-2.3.4.jar 2.6M
4. ecj-4.4.jar 2.3M 用于動態編譯JAVA類，這個在后期的resource設計工具中會有用，是工作流和規則引擎的基礎
5. guava-17.0.jar 2.2M 大愛的google工具包，大小十分感人。。。
6. druid-1.0.7.jar 1.8M 國產的連接池，這個不用介紹了把 oschina 就是這個
7. avaje-ebeanorm-4.1.4.jar 1.6M
8. h2-1.3.173.jar 1.6M 好吧，其實這個用于開發的，沒人在生產使用，jdbc的包跟這個大小差不多，甚至更大
9. jackson-databind-2.4.1.jar 1.1M jackson，這東西也不小。。。。
10. jersey-guava-2.11.jar 962.9K 這個其實是和guava重復的，沒辦法jersey自己搞出來自己用的

說說為啥不自己寫呢？

1. 我沒有那個能力
2. 確實能給開發人員提供便利，就算我不導入，開發人員也會使用其中很多把？
3. 我為什么要重復造輪子？
4. 沒那么多時間去做前輩已經做了的事情，成本太大

種種原因我決定自己寫不太實惠，所以Ameba的身材難免有些感人，但還不至于臃腫，我相信這些成熟的框架不可能寫一堆沒用的代碼。而且既然是全棧，提供好用的接口，身材注定不會小多少，全棧就要考慮很多擴展問題，全面性的問題，所謂魚和熊掌不可兼得。體積小必然是亮點，但是體積小也不意味著好用和快速。框架的所有類庫已經是精挑細選了，我也表示無奈。

關于使用那些事兒

結構

我想我也不用敘述什么，結構大體就這樣，沒有什么約定，只不過要使用maven。

模型

我不知道該怎么描述它，模型在框架的設計中是最重要的地方，承載著數據交互的重要環節，前后端的數據交互，數據庫存儲，參數驗證，VO等等，它是框架的靈魂部分。

資源

這是一個資源的聲明，返回一個HTTL渲染的模板，并且在用戶已經登錄的狀態下會跳轉到首頁 SigninedRedirect 注解關聯的是一個過濾器，用于判斷是否已經登錄，然后跳轉到首頁

一個簡單的注冊，EmailUtil是email模塊提供，使用HTTL渲染內容，前端直接傳輸JSON對象，自動封裝成SignUpEmail對象，框架自動驗證數據。

User.withFinder().where().eq("email", signup.email).findRowCount();

withFinder為框架自動增強，User父類實際并未實現這個方法，sql查詢是linq的形式。

這個是高級一些的，自己構造response

一個user的持久化

User user = new User();
user.email="xxx@xx.com";
user.password="123456";
user.withPersister().save();

應用程序模式

框架內置了三種模式，開發模式，生產模式，測試模式，每一種對應不同的模塊和功能以及日志。開發模式（需要ameba-dev模塊）提供精確的報錯信息的UI展示，詳細的日志輸出，熱加載等。

熱加載

沒什么花頭，就是像play那樣子，刷新頁面就是最新的東西或直接顯示報錯地方的代碼。不過現在內部類熱加載有些問題

發布的目錄結構

現在還沒有提供servlet的容器實現，將來會有的，現在是跑在grizzly上面，一個高性能的NIO框架，沒有之一

conf/application.conf

所有的配置都在這一個文件里面，當然，你還可以創建dev.conf ,product.conf ,test.conf這些配置文件會在啟動的時候根據應用程序模式自動加載

最后

實在困的不行，也不知道你們看的懂不？大概就這樣，還有好多東西沒說，和后續要做的事情，具體看github吧

https://github.com/intelligentcode/ameba/issues