需求背景

框架設計的時間點是2013年年底，當時我正在設計和開發一個視覺化的開發平臺。

這個平臺的首要特點是——使用者通過拖拽元件的方式，設計出表單，進而同步生成表單對映的業務物件的結構——譬如最簡單的例子，使用者物件對映的資料表是什麼，有多少欄位，每個欄位名、欄位型別又是什麼，等等。

我們無法使用mybatis或hibernate這些業內比較常見的orm框架，因為他們本質上需要開發人員編寫程式碼、sql，配置表和物件的關係，而平臺的要求是這個過程是無程式碼化的。

也就是說，僅僅通過配置（本質上會創建出一個XML描述的業務物件），就需要可以通過API對業務物件進行CRUD或者更高階的操作。

設計思路

• 物件的表示

首先要解決的問題是——如果不用編碼的方式，僅僅有一個配置資訊（當然可以把配置文字對映成一個配置類），如何在記憶體中表示當前的業務物件？

1. 程式碼生成器

   當時有很多企業都採用這樣的方式，通過eclipse外掛配置業務物件，然後建立實體類、對映檔案、DAO類、Service類等等。

   這類方法優點是：簡單明瞭，缺點是：意義不大。。。對於專案前期生成程式碼還有點用，但是後期維護、修改還是需要成本，而且本質上修改的內容還需要重新編譯、打包、部署。

2. 弱型別物件

   用一個Map或者陣列，比如使用者是一個Map，公司也是一個Map，只是它們的key的數量不同，這個很好理解，就不多贅述了。

   優點：解決了動態物件的結構問題，缺點：對開發人員來說，在二次開發的時候，不如直接操作類那麼友好（必須知道這個物件是什麼型別，有哪些欄位，欄位對應的值又是什麼型別等等）。

   出於儲存空間和讀寫效能考慮，原生陣列比HashMap更加合適。