天天酷跑小蜜桃|天天酷跑女角色被日
論壇首頁 Java企業應用論壇

忘掉普元EOS、構建自己的企業級快速應用開發平臺

瀏覽 79495 次
精華帖 (0) :: 良好帖 (14) :: 新手帖 (0) :: 隱藏帖 (3)
作者 正文
   發表時間:2008-08-25   最后修改:2009-10-28

希望這篇文章能夠對那些正在或即將開發自己團隊的J2EE應用快速開發平臺的個人或公司能有所啟發! ???

????? 像EOS這樣動輒幾十上百萬的平臺不是每個公司都愿意花錢去買的!因此構建一套窮人級的企業快速開發平臺成了很多團隊的首選,而對于小團隊來說,構建一套自己可以維護的開發平臺才是最重要的。下面,我將以我的平臺的開發過程為例來詳細解析這個過程! ?

“如果能把項目中大量的代碼編寫工作變得輕松,是多好的一件事! ?"

??????? 在使用了AppFuse之后,我有個想法,能不能利用velocity這個優秀的模板引擎,用一種更加直觀的模式,把開發項目中的重復代碼讓它自動生成, 生成之后的基礎代碼,按照實際的需求稍作修改便可以運行,極大的提高工作效率。這樣的話,程序員就可以從大量的重復勞動中解放出來,將精力更多的投入到業 務分析及學習中。

??????? 這個想法一直在我的腦海里橫亙不去,尤其在做了大量的重復模塊后,深刻體會了重復Coding的那種浪費生命的痛苦后,這種沖動尤為強烈。

???????? 離開舊公司,到了新公司之后,由于職位和公司定位的不同,讓我有時間開始把快速開發平臺和自動代碼生成器的開發真正的擺上開發日程上了。

????????? 第一步 ,自動代碼生成器生成 的是業務模塊,那么底層必須有一套框架能夠為它提供支撐,而且這套基礎框架要足夠靈活,并且和單個模塊的耦合性要比較弱。要解耦模塊之間的聯系,勢必要用 到MVC分層設計。感謝Java的開放性,使它有這么許許多多的MVC框架可以使用。我采用的當然是目前最流行的 SSH(Struts+Spring+Hibernate)的組合(以前項目一直在用,也有些成熟的積累),花了三個月的時間,通過一個項目的實際應用來 使這個框架基本成型。其目前功能包括:

??????? 1:靈活完善的權限管理功能(包括用戶管理、角色管理、組織機構管理、資源管理、資源角色映射管理...)。原來計劃采用開源的JGuard來托管這部分 的功能,因為一些特殊的原因放棄了(考慮要和工作流引擎的權限部分做集成),只采用了其權限管理的一些設計思想。

??????? 2:基于Spring的AOP實現的日志和權限管理(通過Spring的代理也將Struts的Action托管了,使的對Action的調用也能被 AOP偵測到),這樣對每個功能的調用,如果需要日志紀錄的話,之間將其配置到Spring的配置文件中就可以了。

??????? 3:UI上實現了類似.NET的Validation驗證,這點很重要,想必大家都深刻體會到利用JavaScript或Struts的驗證機制來實現前端頁面數據驗證的痛苦了吧:),我們實現的功能如下圖所示:

???????

??????? 4、多套UI風格樣式。這個不是很必須,但是作為一套成功的系統,良好的用戶體驗也是必不可少的。

??????? 5、支撐模塊:2套報表引擎(一個是基于JasperReport實現的B/S版本報表;另外一個是類Excel的報表引擎),流程引擎(其實就我個人來看,工作流引擎才是這套系統的靈魂 ,有了它,所有流程性應用包括表單、業務流、權限都可以通過配置并結合Beanshell腳本來獲得 ,以下是我們報表和流程設計器的一些截圖:

?

?

工作流引擎截圖

?

報表截圖

?

???? ?? 6、i18n的支持,由于我們有很多國外的客戶,這塊是必須的。

?

有了這個基礎支撐平臺之后,就可以開始著手開放我們的代碼生成器了。

??????? 第二步 :開發代碼生成器。 AppFuse基于Ant的自動代碼生成模式讓我深惡痛絕,究其原因,一句話--“不夠人性化”,我們做的首先必須考慮可用性,因此決定采用可視化的UI 模式。由于我用的是NetBean編輯器,做可視化的Swing開發不成問題(這點要感謝SUN啊,出了個和VB一樣簡單的IDE)。我實現的代碼生成器 的界面如下:

??

?

怎么樣?是不是夠傻瓜化啊?呵呵,是個人都能用啊!

?????? 從上面大家可以看到,我們這個代碼生成器和Hibernate的POJO對象生成工具類似,也是基于數據庫的模型來生成代碼的,不同的是,我們生成的代碼 范圍更廣,不僅包括了POJO對象暨相應的hbm.xml文件,另外還包括相應的DAO(Server層)、相應的Action、Form類、相關的 JSP文件(list頁面、edit頁面、Excel導出頁面等等)、資源文件及相關的Struts和Spring的配置子文件(Struts和 Spring均支撐將配置拆分成多個配置,我們利用這種特性來減低模塊之間的耦合性。)

??????? 至于數據庫模型的獲得,可以利用JDBC的MetaData(元數據模型) 的功能來獲得,我們目前維護了表的完整的主鍵、外鍵關系(父子表)

?第三步:配置模板。有了可視化的數據庫表映射模型,也獲得了數據庫表及其主外鍵關系的詳細信息,接下來當然是根據這些信息來生成代碼了。這里我們用了強大的Velocity模板 技術,這樣不僅可以靈活的處理復雜的表映射對象之間的關系,也能夠靈活的進行變更升級。而且我們能夠通過所獲得的數據庫模型,在頁面上自動實現基于Javascript的數據驗證“非空驗證、字符長度驗證、數字驗證,日期驗證”。

????????? 呵呵,通過以上3個步驟的工作,我們的基礎開發平臺和自動代碼生成器就大功告成了!目前我們生成的代碼可以直接編譯通過,通過簡單的系統配置后,可以直接在服務器上跑! 由于模板種類多,而且模板中自動實現的代碼功能已經非常完善了,所以一些特殊的業務需求只需要在自動生成的代碼基礎上做簡單修改就可以了!

???????? 基礎開發平臺和代碼生成器投入使用后,對我們項目開發的資源投入的改善是非常明細的,目前基于基礎平臺和代碼生成器的配合,我們已經做了6、7個系統了,平均每個系統的 開發時間至少要比以前節約40%,有的項目甚至達到了80%以上(我們最高的一天,處理了40多個表的增、刪、該、查的功能,及中文本地化)。而且,另外 很重要的一點,生成的代碼無形中統一了程序員的設計風格,我們通過這套開發機制,能夠最大限度的保證我們開發的系統質量,保證模塊可以在不同系統之間的自 由遷移,最大限度的實現復用!在項目開發中節省出來的大量時間,也讓我們可以去研究更多的開源中間件和系統,來增強我們的基礎平臺,從而形成一個良性的循 環!

?我們做了多套模板,能夠針對單表操作,及父子表操作來自由組合搭配。以下就是我們系統的一些功能截圖,除了中文化之外,基本上沒有修改:

單表操作:

父子表關聯操作:

?

?

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

呵呵,這么長時間了,還有人關注這個帖子,謝謝大家的捧場了!
順便通報一下我們平臺目前的狀況:
1、增加了Web Service接口功能,基于spring-xfire實現的,目前基于server這一層的所有接口,在代碼生成器生成代碼(或手工添加接口) 時,xfire會對其自動封裝并對外暴露。并同時集成訪問接口。程序員不用直接接觸wsdl了(安全方面目前只是通過IP過濾來簡單實現)。
?? 這樣的話,同樣基于平臺的A、B兩個獨立系統,可以通過WebService進行相互調用,同時,從本地調用變更為webService調用不需要修改任何代碼,只要修改配置文件的一行定義就可以了!
?? 這個應該算是我們平臺的一個標志性的里程碑了吧!從一定意義上來說,這才真正成為一個開放的平臺,算SOA化了,呵呵!

2、模板更加豐富了,基于工作流應用我們目前已經有了一套通用模式,可以和流程引擎進行無縫結合!針對流程應用的模板可以生成絕大部分引擎相關部 分的代碼,程序員只需要修改流程定義模板的名稱就可以了!同時針對一對多,一對一關系的模板進行了大量優化,能夠適應更多的企業應用場景了!

? 目前的平臺還是主要針對開發人員,是企業應用快速開發 平臺,我們后續規劃將其和我們已經有的一套應用快速搭建 平臺進行整合,以使其能夠同時被業務人員和開發人員使用。簡單業務就由業務人員通過搭建平臺的可視化的流程和表單配置來實現,復雜業務再由技術人員通過開發平臺來實現。
?? 最后再談一下應用快速開發平臺的定位吧,相信這也是大家最近爭論的一個焦點,說有用的有之,說用處不大的也有之。我個人的觀點是:只要你的平臺夠靈活,模 板夠多、夠復雜、兼容的業務場景越多,它就有用,而且很有用;反之,如果平臺底層呆板,模板簡單,它的用處就不大。至于其它的什么維護的便利性什么的我就 不再多說了,免得有吹噓之嫌了,反正大家仁者見仁,智者見智!套用一句常話就是---寒天飲冰水,冷暖自知!
? 我個人目前的工作重點已經轉移到企業應用快速搭建(配置)平臺上來,目前也有些心得,將其和應用快速開發平臺的整合也頗有些成效,后續得空將續開些新博文,和大家共享,希望各位繼續賞臉捧場!!!!

  • 大小: 56.4 KB
   發表時間:2008-08-25  
這種生成器太初級了,只能算工具級的
0 請登錄后投票
   發表時間:2008-08-25  
用appfuse已經3年多了。感覺還行。我們所有的項目都是基于appfuse的。


佩服樓主的精神,不知道是否有共享的打算?

0 請登錄后投票
   發表時間:2008-08-25  
驚鴻逝水 寫道
這種生成器太初級了,只能算工具級的

類似普元的可視化業務流設計實際上在我們的工作流引擎中也有體現,完全可視化的業務流程拖拽設計。

至于代碼生成器,我的設計原則就是一定要盡量簡單,其實其也不可能復雜,它無非就是維護一個數據庫中表、主鍵、外鍵關聯的一個映射而已,生成代碼的復雜性其實都體現在代碼模板中了!

?

0 請登錄后投票
   發表時間:2008-08-25  
業務流程設計也不是什么新東西,關鍵是能定義一個好的業務流程Schema,拖拽愛怎么實現都行。
平臺級的代碼生成器,需要考慮:
1、正向向導生成代碼
2、代碼逆向生成向導
3、必要的編譯檢查。

以上不是一個簡單模板可以實現
0 請登錄后投票
   發表時間:2008-08-25  
驚鴻逝水 寫道
業務流程設計也不是什么新東西,關鍵是能定義一個好的業務流程Schema,拖拽愛怎么實現都行。
平臺級的代碼生成器,需要考慮:
1、正向向導生成代碼
2、代碼逆向生成向導
3、必要的編譯檢查。

以上不是一個簡單模板可以實現


"逆向",服了,怎么生成? 基于Hibernate Model生成數據庫表?
復雜化了,同學!!

另外在樓主的項目中又看到了我的表單驗證框架的影子,

另外樓主可以看下我的項目,為代碼生成器開發一套GUI,還是太麻煩了
http://code.google.com/p/rapid-framework

0 請登錄后投票
   發表時間:2008-08-25  
說實話,樓主的代碼生成器還是很簡單的,有很多的問題沒有考慮到,更不用提什么忘掉eos了,普元的eos還是很厲害的,非常佩服eos studio的開發團隊,盡管是競爭對手...
帖一張我們團隊實現的代碼生成工具的結構圖吧,慚愧的說對eos studio還是參考了一點點滴
哪位感興趣我可以在下面詳細解說

另:velocity是很強大,但是其有一個致命的缺點,我們都在搞代碼生成,我們也都知道大部分代碼生成完之后肯定會被開發人員修改,添加業務邏輯等等,那么如果重新生成呢,就會把開發人員修改的內容覆蓋掉了,在這一點上eclipse jet就做的比較好了,我們也正在考慮從velocity遷移到jet上面
  • 大小: 36.8 KB
0 請登錄后投票
   發表時間:2008-08-25  
驚鴻逝水 寫道
業務流程設計也不是什么新東西,關鍵是能定義一個好的業務流程Schema,拖拽愛怎么實現都行。
平臺級的代碼生成器,需要考慮:
1、正向向導生成代碼
2、代碼逆向生成向導
3、必要的編譯檢查。

以上不是一個簡單模板可以實現

呵呵,要澄清一下,這里的流程引擎可以生成流程業務需要的表單和業務流控制,可以基于流程定義生成持久化對象和后臺存儲,其和這里的代碼生成器完全沒有關系,代碼生成器是用來處理非流程應用的代碼生成工作。
由于流程引擎我們用的是反編譯重構的商用系統,這里就不便透露更多信息了。除此之外,其它用的基本上都是開源產品和組件

0 請登錄后投票
   發表時間:2008-08-25  
badqiu 寫道
驚鴻逝水 寫道
業務流程設計也不是什么新東西,關鍵是能定義一個好的業務流程Schema,拖拽愛怎么實現都行。
平臺級的代碼生成器,需要考慮:
1、正向向導生成代碼
2、代碼逆向生成向導
3、必要的編譯檢查。

以上不是一個簡單模板可以實現


"逆向",服了,怎么生成? 基于Hibernate Model生成數據庫表?
復雜化了,同學!!

另外在樓主的項目中又看到了我的表單驗證框架的影子,

另外樓主可以看下我的項目,為代碼生成器開發一套GUI,還是太麻煩了
http://code.google.com/p/rapid-framework


其實是看你的定位是什么,如果簡單的定位于代碼生成工具的話,那么基本上生成出來的代碼還要經過大量的修改才能被項目開發人員所用
驚鴻逝水說的三點我認為說到了點子上,平臺級的代碼生成器確實要考慮這三點,也就是引導項目團隊的開發方式
0 請登錄后投票
   發表時間:2008-08-25  
lszwycn 寫道
badqiu 寫道
驚鴻逝水 寫道
業務流程設計也不是什么新東西,關鍵是能定義一個好的業務流程Schema,拖拽愛怎么實現都行。
平臺級的代碼生成器,需要考慮:
1、正向向導生成代碼
2、代碼逆向生成向導
3、必要的編譯檢查。

以上不是一個簡單模板可以實現


"逆向",服了,怎么生成? 基于Hibernate Model生成數據庫表?
復雜化了,同學!!

另外在樓主的項目中又看到了我的表單驗證框架的影子,

另外樓主可以看下我的項目,為代碼生成器開發一套GUI,還是太麻煩了
http://code.google.com/p/rapid-framework


其實是看你的定位是什么,如果簡單的定位于代碼生成工具的話,那么基本上生成出來的代碼還要經過大量的修改才能被項目開發人員所用
驚鴻逝水說的三點我認為說到了點子上,平臺級的代碼生成器確實要考慮這三點,也就是引導項目團隊的開發方式


多表關聯操作這部分也可以生成,但開源的話定位還是通用/易用,所以不想在模板文件上搞的過于復雜,難以二次修改,而且view這一層,要定制的東西實在太多.
而現在rapid上的模板文件已經滿足普通的增刪改查需要,簡單修改就可以適應自己的項目.

并且rapid的野心并不只這些,以后的flex,ext2等view界面都會以插件的方式加入進來.
0 請登錄后投票
論壇首頁 Java企業應用版

跳轉論壇:
Global site tag (gtag.js) - Google Analytics 天天酷跑小蜜桃