对代码生成器的一点想法
2019獨角獸企業重金招聘Python工程師標準>>>
本文是《輕量級 Java Web 框架架構設計》的系列博文。
代碼生成器,這個東西很早就有人再搞了。比較典型的應用場景就是中間件平臺,國內的像普元的 EOS?算是做的比較好的。通過圖形化界面的方式拖、拉、拽幾下,一個應用軟件就生成了,因為平臺中已經包括了大量的代碼生成器。當然中間件平臺大多數都是一些商業產品,不是我們這些屌絲買得起的。一般都是金融企業,像銀行、券商這類公司才敢玩。
今天我不談這些商業產品,我要講的是關于代碼生成器的應用,也就是說:為什么要用代碼生成器呢?
我想最有價值的地方就是減小了手工的重復勞動,計算機自動幫我們生成代碼,將我們的雙手解脫出來。然而,這些代碼的格式是我們預先定義好的,也就是模板了,它們需要模板引擎來做解析。
在 Java 這個圈圈里面,做的比較好的模板引擎不多,Velocity 與 FreeMarker 算是比較好的兩款了。但本人還是比較鐘情與 Velocity,因為它足夠輕巧,足夠 Smart!而且還有 Apache 這個老大來保護它。當然,遇到 Velocity 搞不定的情況,不妨再去找 FreeMarker 幫忙吧。
回到今天的主題,我想開發一塊輕量級代碼生成器,使用場景如下:
以一張 product 表為例吧。
Excel 模板大致長這個模樣:
生成的 SQL 腳本是這樣的:
DROP TABLE IF EXISTS `product`; CREATE TABLE `product` (`id` bigint(20) NOT NULL AUTO_INCREMENT,`product_type_id` bigint(20) NOT NULL,`product_name` varchar(100) NOT NULL,`product_code` char(5) NOT NULL,`price` int(10) NOT NULL,`description` text,PRIMARY KEY (`id`) ) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8; 生成的 Entity 類如下: public class Product extends BaseEntity {private long productTypeId;private String productName;private String productCode;private int price;private String description;public long getProductTypeId() {return productTypeId;}public void setProductTypeId(long productTypeId) {this.productTypeId = productTypeId;}// ... 省略其他 getter/setter 方法 } 從數據庫腳本到實體類,其實有一個映射關系(ORM):若表名或列名出現 Java 關鍵字或保留字,則使用一定的規則,將其轉換過來,比如:可在變量名后面加上一個下劃線。
有朋友會問:為什么只生成 Entity 類,其他代碼難道不用生成嗎?
不錯,很多快速開發框架確實將許多代碼都生成了,從后臺到前臺。對于我而言,需要做一些取舍,找準這款工具的定位。它是為 Smart Framework 提供代碼生成的輔助工具,而不是一個強大的代碼生成軟件。我認為,先一步步的來吧,至少表結構和實體定義是比較浪費時間的,我們先把這些代碼生成出來。以后看看還有哪些代碼需要生成,但是完全的代碼生成也有它的弊端,比如:當反復生成代碼時,不小心就會覆蓋掉自己已經修改的代碼,那你就崩潰了。
此外,我們編寫的這份 Excel 文件也可以作為系統的數據字典使用(看 PM 還敢不敢說我們沒有文檔了),對于后期的維護工作也比較合適。
大家看看,有必要做這個小工具嗎?如果需要的話,我同樣也會把實現過程完全開放出來,與大家共同探討。
轉載于:https://my.oschina.net/huangyong/blog/160937
總結
以上是生活随笔為你收集整理的对代码生成器的一点想法的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 华为2013校园招聘上机笔试题
- 下一篇: 关于谷歌地图坐标与百度地图坐标的事