大概在兩年之前，我們采訪過一位擁有十八年開發(fā)經(jīng)驗同時也是一款代碼生成工具Entity Model Studio開發(fā)部經(jīng)理兼主設計師的劉昱老師。上次主要是對其多年從業(yè)經(jīng)驗進行了一次分享（回首往事：十八年的語言分支），這次我們再次次邀請到劉老師為我們解析一下這款開發(fā)工具，同時針對項目開發(fā)時遇到的阻礙進行一次分享。接下來我們就進入正題，開始解析一下這個代碼生成工具。

Entity Model Studio剖析 如何與開發(fā)者親密接觸

Entity Model Studio是一款面向?qū)ο笤O計方法的建模及代碼生成工具，與其他工具的本質(zhì)區(qū)別便在于對產(chǎn)品的定位和理念上。在采訪中劉昱提到：“這款工具的設計理念是為開發(fā)者提供簡單實用的設計開發(fā)工具，并***可能和***程度的提高軟件生產(chǎn)效率。這款工具定位是中小型團隊和基于數(shù)據(jù)庫的應用軟件的開發(fā)。由此在功能上就體現(xiàn)出了兩個差異，***個差異是實現(xiàn)什么樣的功能，第二個差異是一個功能實現(xiàn)到什么程度。”

***個差異是將UML建模設計、數(shù)據(jù)庫設計和代碼生成完全無縫的實現(xiàn)在了一起。與目前主流的一些設計工具相比，很難找到將這三個功能實現(xiàn)在一起的工具。這三部分涵蓋了建模，數(shù)據(jù)庫設計和編碼三個部分，對中小團隊的開發(fā)提供了比較完整的支持。非常適合中小團隊短平快的開發(fā)要求，對具有一定規(guī)模的項目開發(fā)也可以提供非常好的支持。

對于第二個差異可以從上述的三大功能來比較。先說UML建模部分，主流的工具對UML的實現(xiàn)都是以大而全為***目標的，在宣傳上突出權威，全面，準確。而Entity Model Studio由于主要針對定位于中小團隊和數(shù)據(jù)庫應用的開發(fā)，對UML進行了裁剪和簡化，強調(diào)的是針對、易用和易理解性。如針對數(shù)據(jù)庫應用的開發(fā)，UML中的符號和概念都做了更明確，更具體，更易理解的定義，從而在使用上沒有晦澀難懂的內(nèi)容，開發(fā)者亦會覺得親切。在使用上，主流工具的權威性要求開發(fā)者跟隨UML標準，這是以UML為中心的，而Entity Model Studio給出了一個簡化的UML，讓UML為開發(fā)者提供支持，完全以開發(fā)者為中心。

數(shù)據(jù)庫建模部分，同樣沒有采取大而全的做法，相反只是實現(xiàn)了最常用的功能。但在實現(xiàn)的程度上突出了面向?qū)ο蟮臄?shù)據(jù)庫設計，并且和實體建模完全無縫連接。這樣開發(fā)者在完成實體建模的同時就可以完成數(shù)據(jù)庫的設計，這樣的數(shù)據(jù)庫設計讓多態(tài)和繼承特性得到完善的體現(xiàn)，比如索引和觸發(fā)器是可以繼承的，并可以生成到數(shù)據(jù)庫。這是目前主流數(shù)據(jù)庫設計工具都不具備的。主流的產(chǎn)品對數(shù)據(jù)庫的設計更體現(xiàn)一種物理上的設計，比如創(chuàng)建數(shù)據(jù)庫時會要求選擇數(shù)據(jù)庫名和存儲位置等等，是從DBA的視角來看待數(shù)據(jù)庫的。而Entity Model Studio對數(shù)據(jù)庫的設計理念是從開發(fā)者角度來說的，突出了編碼直接能處理和使用到的部分。

代碼生成部分的***特點是Entity Model Studio是基于實體模型生成代碼，所設計即所生成，其它的工具都是基于模板或者數(shù)據(jù)庫生成代碼。另外Entity Model Studio自帶了一個ORM框架，配合這個框架，生成的代碼可以為開發(fā)者提供一個正真實用，強大的面向?qū)ο蟮臄?shù)據(jù)庫開發(fā)接口。和其他代碼生成工具相比，它們都沒有配套的ORM框架，從而影響了功能的實現(xiàn)。另外需要強調(diào)的是為了開發(fā)這個ORM，實現(xiàn)了Entity Query Language（EQL）的技術。在EQL支持下生成的代碼和ORM框架可以發(fā)揮出***的作用。而EQL的實現(xiàn)也是在我們的理念和定位的基礎上最終決策開發(fā)的。

目前這款***版本仍停留在V2.1，不過據(jù)透露，新版本的開發(fā)正在進行，全新的版本主要是完善數(shù)據(jù)庫設計方面的內(nèi)容。在界面和操作便捷方面會有明顯的改善。另外實體模型的設計變化會實時的體現(xiàn)在數(shù)據(jù)庫模型中，這樣開發(fā)者可以實時的知道實體模型和數(shù)據(jù)模型的情況。

#p#

工具是提升效率的***‘藥引’

一個好的工具無論是對于開發(fā)者還是整個項目而言，都是極為重要的，不然也不會有那么多人會去尋找能夠優(yōu)化工作的管理工具。在采訪劉昱時了解到：“Entity Model Studio這個產(chǎn)品的原型來自于實際工作中，我為自己開發(fā)的一個小工具。當時那個項目的情況是計劃3個人4個月完成一個小軟件。后來由于種種原因需要我一個人完成，但是工作量增加了1倍到1.5倍。為了保證進度，我在項目中使用了這個工具并且在項目開發(fā)過程中逐步完善。最終是花了7個月的時間完成了任務。從這個實際情況來說，工具帶來的效率提升不可能是簡單的乘法再除法這么算的，實際的數(shù)字可以作為一個參考。但是這個工具的作用是不可缺少的，帶來的效率提升是非常明顯的。否則是不可能在7個月內(nèi)完成這些開發(fā)任務的。”

再說UML。UML的優(yōu)點以及在開發(fā)上的作用，這個是不用多說的，有太多太多的資料在介紹，UML本身的地位也足夠說明了。但是在實際工作中，UML的使用往往停留在設計上，將一個軟件結構或者功能表達清楚就完成任務了。當然這部分工作非常重要，也是亮點，但是這依然不夠?；诋a(chǎn)品的理念和定位，UML可以被更明確的定義和裁剪，這樣設計可以更好的影響開發(fā)。目前Entity Model Studio主要關注在靜態(tài)模型上，這部分就體現(xiàn)了這個理念。比如：實體模型和數(shù)據(jù)庫設計無縫連接，這樣完成一個設計得到兩個模型，并且由實體模型決定數(shù)據(jù)庫?；谀Ｐ蜕纱a，模型變化，代碼也會跟隨改變，有了基于模型的代碼后，還開發(fā)了EMLib，再次從編碼層面為開發(fā)提供便利，提高開發(fā)效率。這樣一來，Entity Model Studio中的UML建模和開發(fā)是緊密結合的，不僅僅是設計，而是在多個步驟中都為開發(fā)及編碼提供有力的支持。相比其它建模工具相比Entity Model Studio要貼心多了。

自帶的ORM為開發(fā)者提供了一個完備的面向?qū)ο髮ο蟮臄?shù)據(jù)庫開接口，不只是完成對象映射的工作。雖然EMLib以ORM為稱呼，但是在從一開始就以超越一般ORM理念的定位來開發(fā)這個框架。其目的是讓Entity Model Studio生成的代碼真正能夠被使用在真實的開發(fā)工作中，同也從提高開發(fā)效率的角度為程序員提供盡可能好的支持。所以在功能上這個框架有明顯區(qū)別一般ORM框架的地方。

例如這個框架同時提供了ORM方式和傳統(tǒng)方式操作數(shù)據(jù)庫，但是EQL卻都可以在這兩種不同方式下使用。再如增強的關系操作，可控制深度的級聯(lián)操作，全局對象查詢，內(nèi)存和數(shù)據(jù)庫一致的事務操作等等，這都是一般ORM框架不具備的，這些特色都可以提高開發(fā)效率，提供編碼上的便利。關于這個ORM的更多的介紹可以參考這篇博文：《面向?qū)ο蟮臄?shù)據(jù)庫開發(fā)--再論ORM 》

#p#

也曾失敗過多次的開發(fā)工具

想法往往是一個項目的開始，到后來的執(zhí)行與***次完善這段期間往往會有著多樣的艱辛與阻礙，而從這些中得出的經(jīng)驗，往往會讓后人少走不少的彎路。即便你擁有嫻熟的開發(fā)技術，在項目面前往往也會束手無策。

Entity Model Studio從一開始時亦是這樣，在采訪中得知，1998,1999年時便有了***次開始研發(fā)的想法，當時以反復推倒重來的方式先后做了四次，最終都是以失敗告終的，不得已，實際開發(fā)工作只能就此停止。

此后，隨著各項技術的發(fā)展，比如UML，設計模式，ORM等等，我的想法也在不斷的完善，加上自己的經(jīng)驗積累，讓最初的想法慢慢的變得成熟。直到2006年的1月1號，再一次開始寫下***行代碼，此后完成過幾個試驗版本，2009年開始組建團隊，2012發(fā)布***個實用版本。

同時開發(fā)過程中始終存在著一個巨大的阻礙，便是判斷。這種判斷往往普通到只是一個簡單疑問句，但是決策解決卻非常棘手。比如，在開發(fā)時序圖時是否支持這樣一個功能，當拖動一個消息后時序圖中相關聯(lián)的消息和消息生命線自動重新調(diào)整位置。如果支持這個功能的話，使用者會非常方便。對于一貫使用微軟產(chǎn)品的人來說，實在是應該實現(xiàn)。但是從另一方面上來說，考察的幾個主流產(chǎn)品，除了微軟的以外都沒有實現(xiàn)這個功能，同時實現(xiàn)該功能具有一定的難度。那么這個時候如何決策做與不做就很是棘手。需要綜合各個因素，像是能力，風險，成本等等來考慮問題。

另一個例子是為了開發(fā)EMLib，開發(fā)團隊獨立開發(fā)了一個測試工具。當時的困擾在于有現(xiàn)成的測試工具可以使用（但是都不夠理想），如果自己開發(fā)需要相當?shù)墓ぷ髁浚谥鏖_發(fā)任務都吃緊的情況下是否需要來做？當時在非常猶豫和勉強的心情下做出的開發(fā)決定。

非常幸運的是，事實證明如果沒有這個工具，那么EMLib的整體開發(fā)工作量將會是十幾倍甚至幾十倍的增加。當然還有其它的一些例子，比如開發(fā)過程中對開發(fā)方法論層面的認識，反思和驗證都是非常折磨人的，也非常具有挑戰(zhàn)。這些問題的解決往往是以一種嘗試+證據(jù)+“悟道”的方式來完成的，當然有時候運氣也是原因之一。

總體來說頭疼的問題應該都是具有一定復雜性和不確定性的問題，解決這類問題的關鍵更多的是在問題的認識和分析上，而不是一個可行的能夠解決問題的方法本身。因為嘗試解決問題有可能是以認識到問題無法被解決作為結束的。這方面展開談論的話是可以單獨作為一個話題來說的。如果感興趣的可以參看《十八年開發(fā)經(jīng)驗分享：學習篇》。

Entity Model Studio&Entity Model Lib&Entity Query Language

在官網(wǎng)中，我們分別看到了Entity Model Studio、Entity Model Lib、Entity Query Language這三款產(chǎn)品的介紹，同時網(wǎng)站還介紹了一些解決方案的內(nèi)容。為此我們特意邀請劉昱老師做了明確的介紹：

Entity Model Studio就是我們的主打產(chǎn)品，是一個建模設計工具。Entity Model Lib（EMLib）是一個ORM框架，其使用了Entity Model Studio生成的模型文件，為開發(fā)者使用生成的代碼和完成開發(fā)任務提供便利。需要強調(diào)的是EMLib不僅僅只是一個ORM框架，而是給開發(fā)者提供了一個完備強大的面向?qū)ο蟮臄?shù)據(jù)庫開發(fā)庫。EMLib存在的價值在于讓開發(fā)者設計的靜態(tài)模型可以直接的開發(fā)中使用起來，而不是一個個的模型圖，提高開發(fā)及編碼的效率。

Entity Query Language的官方命名是實體查詢語言，簡稱是EQL。這是一個基于宿主語言的開發(fā)接口，以可編程方式構造各種Sql語句對象，以便EMLib完成相關的數(shù)據(jù)庫操作，是對EMLib一個有力的也是必須的補充。EQL的特點之一是既可以結合EMLib完成ORM操作，也可以通過語句對象生成對應的Sql文本，然后再使用。所以也是可以脫離ORM框架獨立使用的。另外可編程的方式擺脫了字符串拼接方式構造Sql文本的缺點和麻煩，在構造條件時更能體現(xiàn)出優(yōu)勢。這些也是可以提高編碼效率的一個方面。

網(wǎng)站上列出的解決方案主要是屬于技術服務和支持性質(zhì)的，主要包括使用Entity Model Studio中的疑問解答，UML培訓和軟件設計及外包服務。這個可以看做是產(chǎn)品延生部分的內(nèi)容。培訓是我們提供教程或者資料，也可以通過在線溝通的方式完成，如果各方面的條件許可的話也可以提供線下培訓。Entity Model Studio的學習成本是很低的，近乎為零，其原因是UML已經(jīng)簡化了，而且使用到的相關知識都是日常開發(fā)中經(jīng)常接觸的內(nèi)容。所以使用Entity Model Studio是很容易的。

無論是從產(chǎn)品還是服務，廣聯(lián)科技（WideUnion）都在各個環(huán)節(jié)體現(xiàn)著自己的理念，從開發(fā)，到學習（降低學習成本這點亦是一種理念的體現(xiàn)）。所謂效率的提高，為開發(fā)提供便利的前提是程序員付出的工作量不能增加（少量增加是可能的），至少是不能等比例增加。在此基礎上再有所得的增加才是正真意義上的效率提升，簡單來說就是做一樣多，獲得更多。所以學習成本作為一種付出，是非常非常值得注意的。