大概在两年之前，我们采访过一位拥有十八年开发经验同时也是一款代码生成工具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主要关注在静态模型上，这部分就体现了这个理念。比如：实体模型和数据库设计无缝连接，这样完成一个设计得到两个模型，并且由实体模型决定数据库。基于模型生成代码，模型变化，代码也会跟随改变，有了基于模型的代码后，还开发了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）都在各个环节体现着自己的理念，从开发，到学习（降低学习成本这点亦是一种理念的体现）。所谓效率的提高，为开发提供便利的前提是程序员付出的工作量不能增加（少量增加是可能的），至少是不能等比例增加。在此基础上再有所得的增加才是正真意义上的效率提升，简单来说就是做一样多，获得更多。所以学习成本作为一种付出，是非常非常值得注意的。
