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

Entity Model Studio剖析 如何與開發者親密接觸

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

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

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

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

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

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

#p#

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

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

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

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

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

#p#

也曾失敗過多次的開發工具

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

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

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

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

另一個例子是為了開發EMLib，開發團隊獨立開發了一個測試工具。當時的困擾在于有現成的測試工具可以使用（但是都不夠理想），如果自己開發需要相當的工作量，在主開發任務都吃緊的情況下是否需要來做？當時在非常猶豫和勉強的心情下做出的開發決定。

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

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

Entity Model Studio&Entity Model Lib&Entity Query Language

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

Entity Model Studio就是我們的主打產品，是一個建模設計工具。Entity Model Lib（EMLib）是一個ORM框架，其使用了Entity Model Studio生成的模型文件，為開發者使用生成的代碼和完成開發任務提供便利。需要強調的是EMLib不僅僅只是一個ORM框架，而是給開發者提供了一個完備強大的面向對象的數據庫開發庫。EMLib存在的價值在于讓開發者設計的靜態模型可以直接的開發中使用起來，而不是一個個的模型圖，提高開發及編碼的效率。

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

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

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