1. 程式人生 > >深入淺出教你做一個快速開發平臺

深入淺出教你做一個快速開發平臺

快速開發平臺,重點在於快,要快無非就是兩種手段:

1、生成程式碼

2、重用模組

詳細看如下的分支圖

就第一種情況生成程式碼來說,是每個快速開發平臺必備的,基本上所有的快速開發平臺都能生成CRUD,從jsp頁面到java程式碼都可以,當然能不能生成直接可用的程式碼就似乎平臺的功力了,有些是生成後,

需要手動去調整某些東西才能執行,例如,一些表單的驗證,或者一些需要配置檔案,因為你生成的CRUD,可能是需要在某個配置檔案中,插入某段配置,所有往往這個也需手動去調整。

但這裡有重要一點,CRUD都是屬於比較規範的程式碼,那不規範的程式碼如何生成呢?例如,一個登陸過程,或者一個報表統計的過程,這些非規範的程式碼生成在後面我會說到。

這裡先繼續說一下重用的另外一個手段:重用模組,很多公司都有自己的一套所謂的框架,這個也是重用模組的一種常見手段,基本上就是提取出共用的功能函式或者必要的過程段,

然後加以整理,從而形成一個通用的模組集。

例如,通用的許可權管理平臺等,或者通用的方法庫等,這些整理出來後,一般情況下往後的專案之需要進行使用即可,而不需再重新開發,從而達到快速開發的目的。

繼續說一下如何生成程式碼,這裡還是說生成的是規則的程式碼,類似CRUD這些的程式碼。要實現生成規則程式碼的目的,可以有很多方法形式,

常見的有如下三種:

1、居於瀏覽器做一個web平臺,然後在web平臺裡面可以針對某些表或者pojo等,通過介面配置來生成程式碼。

2、可以居於eclipse體系之上做外掛

3、當然可以自己寫一些桌面應用,在.net 領域比較常見些,java領域也有人是通過dephi做桌面應用的 快速開發工具的

當然還有第4種,就是寫個main函式作為入口,然後讀取相關模板和配置檔案進行生成規則程式碼,連介面都不要了。

這三種方式,我就不多說了,下圖分別對這三種方式的優缺點總結,當然這個是我個人的見解。

以上基本上都在說如何生成規則的程式碼,那不規則的程式碼,如何生成呢?有必要生成嗎?

嗯,對於第二個問題,我們先擱置,這個是不是我寫個文章的目的。

我重點說一下應該如何生成不規則的程式碼。

先假設一個經典的案例:

一個登陸的過程吧:

1、使用者先是開啟登陸頁面,然後輸入使用者名稱、密碼

2、然後按登陸按鈕

3、伺服器端程式,接收到請求,然後從request中取出 使用者名稱和密碼

4、然後使用使用者名稱和密碼,進行資料庫查詢

5、如發現的有對應的記錄,則轉向成功登陸的頁面

6、如果沒有對應的記錄,則轉向登陸頁面

以上的過程中,伺服器端執行的程式段,我們可以這樣去劃分層次:

1、接收請求(使用者名稱、密碼)

2、執行邏輯(資料庫查詢)

3、結果返回(根據查詢的結果,從而轉向兩個不同的頁面)

那麼我們怎樣來生成以上那段不規則的程式碼呢?

嗯,需要把上面三個程式段抽取為三個模型來處理,

第一個模型:接受引數模型

第二個模型:執行邏輯模型

第三個模型:返回結果模型

既然有了模型,那如何為這些模型賦予相關的屬性呢?從案例出發,

接受引數的模型,最重要的屬性,當然是 接受怎樣的引數了,然後這些引數應該定義為怎樣的型別了。

可以這樣設計這個模型:

接受引數模型{

引數列表{引數名、引數型別;引數名、引數型別;.....}

}

那執行邏輯模型呢?在這個案例裡面,執行的邏輯是,把接收到的使用者名稱和密碼拿出來,然後去查詢資料庫表,再返回結果,

如果按照我們寫程式碼的習慣,會把這個過程獨立成為一個方法,然後使用者名稱和密碼就是輸入的引數,而查詢的結果,我們可能使用int來返回,

返回1,就代表是有,如果返回 0 就代表沒有(當然,你使用布林型別也可以,這個不影響模型的抽取)。

那麼這個模型可以設計如下:

執行邏輯的模型{

輸入引數{引數名、引數型別;引數名、引數型別;.....}

返回引數{引數型別}

}

這樣一看,貌似是缺乏些什麼?那我所要執行的真正邏輯在哪表示了?還沒有包含啊?對的,缺乏這個,那在這個模型裡面,如何表示?嗯,要不,我們先從一個簡單的角度去考慮:

假如你已經有一個登陸方法了,你只需要傳入使用者名稱和密碼,就能返回1表單有該使用者,0代表沒有。那麼以上的模型就可以表示如下:

執行邏輯的模型{

輸入引數{引數名、引數型別;引數名、引數型別;.....}

返回引數{引數型別}

執行的方法    //什麼包下什麼類什麼方法

}

返回結果模型呢:

返回結果模型,這裡根據不同的結果返回不同的jsp頁面,不妨,我們就用一個jsp模型,來代表返回結果的模型

如果我們寫java程式碼,一般都是這樣寫:

結果不同就forward不同的頁面

然後在forward頁面前,我們可能要將一些要輸出到jsp頁面的變數設定的到request中的Attribute中去,例如,如果我們這個案例中,如果沒有該使用者的話,返回的是登陸頁面,

我們需要在登陸頁面中顯示“你輸入的使用者名稱或者密碼有誤”,這樣一個反饋資訊給使用者知道。

所以,我們的返回模型、也就是jsp模型可以這樣設計:

返回結果模型(jsp模型){

返回引數{引數名、引數名....}         //可能是返回多個

jsp頁面的路徑     //需要轉向的jsp頁面路徑

}

有了模型後,那該如何生成程式碼?模型只不過是描繪這一個請求處理過程的細分單元罷了,嗯,那怎樣生成程式碼呢?

模型怎樣去描繪這個請求處理過程呢?

這裡需要一個編輯器,然後在這個編輯器上面使用模型來描繪這個過程。例如,如下的登陸截圖

要實現這樣一個編輯器,有很多技術可以實現:flex、gef、gmf等,或者你自己寫個swing拖拽器也可以。。

在編輯器裡面用模型描繪完這個請求處理過程後,怎樣生成程式碼?

生成程式碼比較簡單,過程其實上和生成CRUD是一樣的,都是讀取某些資訊,然後使用模板引擎freemarker或者其他的,然後套用到某個模板上面,即可生成對應的程式碼了。

但這裡得注意,模板?那這個模板應該怎樣寫呢?

和我們寫普通模板一樣,先是寫可以跑通的程式,然後把非公用的屬性挖走,就是模板了,

例如,CRUD的模板,我們是從CRUD程式裡面挖走 哪個表,什麼欄位這些,當然有時候是必須加些判斷來控制程式碼的生成。

這個請求過程的模板,也是如此,先按 模型思想,就是 “接受引數”模型、“執行邏輯”模型、“JSP”模型,寫出程式來,跑通後,

再把非公用的東西挖走,例如,接受什麼引數啊,執行什麼方法啊,轉向什麼頁面啊等挖走,就成了模板了。

實際上要讓快速開發平臺能生成 非規則的原始碼,重點是在於,對請求處理過程的模型抽取,每個公司都有自己的抽取方式,就例如上面的案例,但始終都離不開 “合理的模型能組合成為一個完成的請求處理過程” 的原則。

上面的 登陸過程圖實際上是最簡單的一種請求處理過程抽取。

你在開發專案的時候,往往會需要返回ajax,,那就多加一個ajax模型吧,,可以!

有時,可能是你底層的方法庫是沒有的,那需要自己手動寫一個方法,,然後這個方法我要嵌入到這個請求處理圖中去,,那就多加一個自定義方法的模型吧,,可以!

。。。其他情況,依然這樣處理。

事實上,要抽籤合適的模型需要一個循序漸進的過程,但可以參考一些現有的開發平臺,他們已經抽取好了,然後根據他們的模型,按照自己的思維、技能進行調整,得到自己想要的模型集。

模型的抽取是按照每個人的思維方式不同而不同,因人而異,沒有標準化。

當然你也可以利用這種生成非規範程式碼的思想來開發工作流程式,也可以用來開發工控的一些圖形化程式設計工具,或者是電信行業的ivr程式都可以。


小結一下:

要生成非規則性的程式碼,處理過程無非就是,先寫一個可以跑通的程式,然後在這個程式裡面把異性的元素抽取出來,變成模型(可以理解為一個變數),然後生成程式碼的適合,就是將這個變數賦值,

再和原來被抽取的程式段結合,即可。

關鍵的地方是在應該怎樣抽取異性元素才是更適合,另外,一個關鍵點是抽查出來的異性元素(模型)怎樣賦值的問題,這需要一個工具,才能更好的把賦值和生成程式碼集合起來。

後話:

當然在快速開發平臺中,生成程式碼,不管是規則或者非規則,都只是部分功能而已,還有其他很多功能,所以,我個人感覺快速開發平臺最好能依賴eclipse體系而已建立,以達到重用eclipse系統本身某部分功能的目的,從而減少開發量。