大约两年前，我们采访了一位拥有18年开发经验的代码生成工具EntityModelStudio的开发经理兼首席设计师老师刘宇。上次主要是分享他多年的工作经验（回顾：18年语支），这次我们再次邀请刘老师为我们分析这个开发工具，同时为项目开发。分享的障碍。接下来我们进入正题，开始分析这个代码生成工具。EntityModelStudio剖析如何与开发人员取得联系EntityModelStudio是面向对象设计的建模和代码生成工具。与其他工具的本质区别在于产品的定位和概念。在采访中，刘宇提到：“这款工具的设计理念是为开发者提供简单实用的设计开发工具，最大程度地提高软件生产效率。这款工具定位为中小型-sizedTeam和基于数据库的应用软件开发。从这里来看，在功能上有两个区别，第一个区别是实现什么样的功能，第二个区别是功能实现到什么程度。”**第一个区别是UML建模设计、数据库设计和代码生成一起无缝实现的。相对于目前一些主流的设计工具来说，很难找到一个同时实现这三个功能的工具。这三个部分涵盖了建模、数据库设计这三个部分和coding，为中小团队的开发提供了比较完善的支持，非常适合短期的开发需求f中小型团队，也可以为具有一定规模的项目开发提供很好的支持。对于第二个区别，可以从以上三大功能上进行比较。先说UML建模部分。主流的UML实现工具，都是以大而全为目标，宣传的权威、全面、准确。而EntityModelStudio对UML进行了剪裁和简化，因为它主要针对中小型团队和数据库应用的开发，强调针对性、易用性和易理解性。例如，对于数据库应用的开发，UML中的符号和概念都被定义得更清晰、更具体、更容易理解，使用起来没有晦涩难懂的内容，开发者也会感到亲切。在使用上，主流工具的权威性要求开发者遵循UML标准，以UML为中心，而EntityModelStudio提供了简化的UML，让UML为开发者提供支持，完全以开发者为中心。数据库建模部分也没有采取全面的方式，而是只实现了最常用的功能。但在实现程度上突出了面向对象的数据库设计，与实体建模完全无缝对接。这样开发人员就可以在完成实体建模的同时完成数据库的设计。这种数据库设计充分体现了多态和继承的特点，比如索引和触发器可以被继承，可以生成到数据库中。这是目前主流的数据库设计工具所不具备的。主流产品的数据库设计体现的是一种物理设计。比如在创建数据库的时候，会要求你选择数据库名称和存储位置等，以DBA的角度来看待数据库。EntityModelStudio对于数据库的设计理念是站在开发者的角度，突出代码可以直接处理和使用的部分。代码生成部分最大的特点是EntityModelStudio根据实体模型生成代码，设计什么生成什么。其他工具基于模板或数据库生成代码。此外，EntityModelStudio还带有一个ORM框架。有了这个框架，生成的代码可以为开发者提供一个真实而强大的面向对象的数据库开发接口。与其他代码生成工具相比，都没有配套的ORM框架，影响了功能的实现。另外，需要强调的是，为了开发这个ORM，实现了EntityQueryLanguage（EQL）技术。EQL支持和ORM框架生成的代码可以发挥最佳作用。EQL的实现也是基于我们的理念和定位的最终决策制定。目前这个最新版本还是V2.1，不过据介绍，新版本的开发正在进行中，新版本主要是完善数据库设计方面的内容。在界面和操作的便利性上会有明显的提升。此外，实体模型的设计变更会实时反映在数据库模型中，让开发者实时了解实体模型和数据模型的情况。#p#工具是提高效率的工具***'幺引'一个好的工具对于开发者和整个项目来说都是极其重要的，不然也不会有那么多人找工作可以优化管理的工具。在采访刘宇时了解到：“EntityModelStudio产品的原型来自于我在实际工作中为自己开发的一个小工具，当时计划3个人4个月完成这个项目。后来，由于种种原因，需要一个人完成，工作量却增加了1到1.5倍，为了保证进度，我在项目中使用了这个工具，并在项目开发过程中逐步完善。最终，用了7个月的时间完成了任务。从这个实际情况来看，工具带来的效率提升不是简单的乘除法就能算出来的。实际数量可以作为参考。但是这个工具的作用是不可或缺的，它带来的效率提升是非常明显的。否则，不可能在7个月内完成这些开发任务。》说说UML，UML的优点和它在开发中的作用，这个不用多说，介绍的资料太多，UML本身的地位就足以说明了。但是在实际工作中，使用UML往往停留在设计层面，把一个软件的结构或功能表达清楚就可以完成任务。当然这部分工作很重要，也是一个亮点，但还是不够。基于概念和定位产品，UML可以更清晰的定义和裁剪，这样的设计可以更好的影响开发，目前EntityModelStudio主要关注静态模型，这部分体现了这个概念。例如：实体模型和数据库设计是无缝的连接起来，这样一个设计可以得到两个模型，实体模型决定数据库。根据模型生成代码，代码会随着模型的变化而变化。有了基于模型的代码后，EMLib也开发了ped从编码层面方便开发，提高开发效率。这样，EntityModelStudioUML建模和开发紧密结合，不仅仅是设计，而是在多个步骤中为开发和编码提供强有力的支持。与其他建模工具相比，EntityModelStudio要贴心得多。ORM为开发者提供了完整的面向对象的数据库开放接口，而不仅仅是完成对象映射的工作。EMLib虽然叫做ORM，但是它从一开始就以超越一般ORM概念的定位开发了这个框架。其目的是让EntityModelStudio生成的代码能够用于真正的开发工作，从提高开发效率的角度为程序员提供最好的支持。因此，这个框架在功能上与一般的ORM框架有明显的区别，例如，这个框架提供了ORM和传统两种操作数据库的方式，但是EQL可以在这两种不同的方式中使用。再比如增强的关系操作，可以控制深度的级联操作，全局对象查询，内存和数据库一致的事务操作等等，都是一般的ORM框架所没有的。这些特性可以提高开发效率并提供编码便利。关于这个ORM的更多信息，可以参考这篇博文：《面向对象的数据库开发--再论ORM》#p#也失败了很多次。开发工具的想法往往是一个项目的开始，在后来的实施和初步完善的过程中往往会遇到各种艰难险阻，而从中得出的经验，往往可以让后人少走很多弯路。即使你拥有熟练的开发技术，在项目面前也常常束手无策。EntityModelStudio从一开始也是如此。据采访，1998年和1999年，第一次有开始研发的想法。如果失败了，也是不得已而为之，实际的开发工作也只能到此为止了。此后，随着各种技术的发展，如UML、设计模式、ORM等，我的想法不断完善，随着自身经验的积累，原有的想法也逐渐成熟。直到2006年1月1日，我又开始写第一行代码。从那以后，我完成了几个实验版本。2009年开始组队，2012年发布第一个实用版，同时在开发过程中始终存在一个巨大的障碍，就是判断。这种判断往往很常见，只是一个简单的疑问句，但决策解决却很棘手。比如开发时序图时是否支持这样的功能，当消息被拖动时，时序图中关联的消息和消息生命线会自动重新调整。如果支持这个功能，对用户来说会很方便。对于那些一直使用微软产品的人来说，它真的应该成为现实。但另一方面，除了微软的主流产品都没有实现这个功能，而且很难同时实现这个功能。所以这个时候怎么决定做还是不做，是很棘手的。需要综合考虑能力、风险、成本等各种因素来考虑问题。再比如，针对EMLib的开发，开发团队自主开发了测试工具。当时的麻烦是有现成的测试工具可用（但都不是理想的）。如果自主开发的工作量相当大，在主要开发任务比较紧的情况下是否有必要去做？开发的决定是在当时非常犹豫和不情愿的情况下做出的。幸运的是，事实证明，如果没有这个工具，EMLib的整体开发工作量将增加十倍甚至几十倍。当然，还有其他的例子，比如在开发过程中对开发方法论的理解、反思和验证，都是非常折磨和挑战的。这些问题的解决往往采用审理+证据+“悟道”的方式。当然，有时候运气也是原因之一。一般来说，头痛问题应该是具有一定复杂性和不确定性的问题。解决此类问题的关键更多在于对问题的理解和分析，而不是能够解决问题本身的可行方法。因为尝试解决问题可能会以发现问题无法解决而告终。谈及这方面的内容可以作为一个单独的话题来讨论。有兴趣的可以参考《十八年开发经验分享：学习篇》。EntityModelStudio&EntityModelLib&EntityQueryLanguage在官网上，我们看到了EntityModelStudio、EntityModelLib、EntityQueryLanguage这三个产品的介绍，网站上也介绍了一些解决方案。为此，我们特地请来了刘宇老师，给大家一个明确的介绍：EntityModelStudio是我们的主打产品，一个建模和设计工具。EntityModelLib（EMLib）是一个ORM框架，它使用EntityModelStudio生成的模型文件，为开发者使用生成的代码和完成开发任务提供便利。需要强调的是，EMLib不仅仅是一个ORM框架，而是为开发者提供了一个完整而强大的面向对象数据库开发库。EMLib的价值在于开发者设计的静态模型可以直接用于开发，而不是一张一张的模型图，从而提高开发和编码的效率。EntityQueryLanguage的正式名称是EntityQueryLanguage，简称EQL。这是一个基于宿主语言的开发接口。它可以通过编程方式构造各种Sql语句对象，使EMLib完成相关的数据库操作。它是对EMLib的强大且必要的补充。EQL的一个特点是可以结合EMLib完成ORM操作，也可以通过语句对象生成相应的Sql文本，然后使用。所以它也可以脱离ORM框架独立使用。另外，可编程的方式摆脱了通过字符串拼接构造Sql文本的弊端和麻烦，在构造条件的时候更能体现出优势。这些也是可以提高编码效率的一个方面。网站上列出的解决方案主要是技术服务和支持性质的，主要包括EntityModelStudio中的问题解答、UML培训、软件设计和外包服务。这可以看作是产品扩展部分的内容。培训就是我们提供教程或者资料，也可以通过在线交流的方式完成。如果条件允许，也可以提供线下培训。EntityModelStudio的学习成本很低，几乎为零，因为对UML进行了简化，所用到的相关知识都是日常开发中经常接触到的内容。所以使用EntityModelStudio很容易。无论是从产品还是服务，WideUnion从开发到学习的每一个环节都体现了自己的理念（降低学习成本也是理念的体现）。所谓提高效率，为开发提供便利的前提是程序员的工作量不能增加（小幅增加是可以的），至少不能按比例增加。在此基础上，收入的增加才是真正的效率提升。简单来说，就是做的越多，得到的越多。所以，学习的成本作为支付是非常非常值得注意的。
