请教一个关于MDA或者叫平台或者叫代码生成器的困惑
看到讨论平台的很多,我觉得软件技术的变革和改进,都是为了需求而改变的,可以说需求驱动了软件开发方法和技术的变革。
在以前,我一直就有一种思路,把软件的业务部分和技术部分分离开,做业务的业务专家,不需要知道ajax、spring、ext,oo的概念,总之,过去的,现在的,未来的流行技术都是不需要知道的。他只需要对终端用户的需求去进行描述,我需要什么,比如我需要一个ig的界面,需要一个表单录入哪些信息,需要做哪些校验,这些数据该做什么样的处理,应该怎么对这些数据进行测试,流程应该怎么流转。
通过业务和实现分离,让业务专家甚至是客户本身就能拥有定制业务的能力。
而这些描述是受限制的,尽量地满足最佳实践的,比如如果你描述客户需要一个列表,那么ok,你可以描述按什么检索,按什么排序,一页显示多少行,数据从哪里取(这里直接写从哪张表里取,系统自动转成o/r mapping,生成所需要的pojo和各种配置文件,业务专家不需要知道什么是o/r mapping),是否支持锁定列等等。用最容易理解的参数描述,描述出这一个列表的各种特征。然后系统进行翻译,生成可以执行的oo代码。这个好处就是生成的UI界面非常好,因为我们专门有人研究UI这一块,都是按最佳实践来的,而业务专家本身不需要知道怎么实现的,只需要按预先设定好的模型参数填进去就行了。唯一的缺点就是,界面只能有几种,业务专家本身是不能发挥他的想象力的,只能把需求提供到平台组,加以改进,但是这个缺点的好处是,生成的界面很统一,而且是最佳实践,一个地方学会了,就都会了,而且没有致使的缺陷,业务专家所能提的,无非是一些锦上添花的UI需求,有更好,没有也不影响使用。
我在一个大客户那边得到过验证,效果非常好,客户的信息化部门,本身对自身的业务很熟,受限于软件方面的知识,他们年龄都大了,不愿意再深入到技术里面,这样通过我们给他们提供的这种分离机制,他们可以很轻松地把权限定制好,把流程定制好,把每一个节点的展现定制好,然后一运行,整个系统就ok了,整个过程他们不知道什么是oo,不知道继承,不知道多态,到了最后,都是客户自己在定制啊定制,我们因为业务不熟悉,已经都快加不进去了,除了在底层进行支持,比如把客户定制好的要求转成最优的ui界面,让客户使用时能感觉到非常地舒服,剩下的工作就等着数钱了,而客户对我们的评价还非常高,为什么呢?因为他们定制出来的业务,基本不出错,很稳定,什么样的UI有什么样的功能,都是确定的。
但是,我在这里遇到了一个最大的问题,就是我觉得我这是一种MDA,模型驱动,跟omg的概念很象,但是这跟omg的模型不怎么搭边,而且模型也没有用uml,因为对业务专家来说,让他们学uml,不如我们自己定义的一套说明容易理解,我这个思路放在mis领域里却非常好用,除了快速、稳定以外,客户本身只要能够理解数据库里的表和字段的概念,再懂业务,一天就能上手,一周就能自己定流程,定菜单,定界面,定权限等等,在我们划好的这一亩三分地上盖起高楼,一但盖错了,立马重新翻盖,速度非常快,以功能点为例,比在一个基础框架下面coding实现出来的功能效率要高3倍左右,关键是不用程序员,节省成本,客户自己还愿意干。
大家觉得这种思路有哪些问题,有哪里需要改进的地方?因为我们是经过特大型国企这样的客户验证过的,模式确实成功,请大家不要再以这个不oo为理由进行攻击,我们转换器转换以后的代码,是oo的,包括反射,aop,ioc,o/r mapping、ajax、ext等好用的都用到了,甚至junit我们都考虑到了,测试代码自动生成。
1 楼 yimlin 2007-12-21 能提高效率就行!uml不uml都是假的!那种试图提供通用化的能力的,估计都会陷入06z所说的困境中。
你们的模式有一个很大优势:实施人员是客户的信息化部门,而不是客户的业务人员 2 楼 liyong_2003_cn 2007-12-21 当时那个项目前期,引擎没有开发出来的时候,客户对我们持相当的怀疑,这是那个项目第三遍在做,以前几百万的投资都打水漂了,前两次的情景历历在目,一堆程序员在coding,当整出个东西来,业务人员就说不行,到了后来,业务人员也不来了,你们自己玩吧,不陪了,所以在我这个项目的初期,我都做好准备了,万一不成功就成仁,虽然我当时有七成把握,但是没见别人做过。
等引擎开发完毕,把信息部门的人给喜得不行,天天加班定制业务,他们很有成就感,因为虽然那些漂亮的UI不是他们自己写出来的,可是那是他们给出的思想,怎么校验,流程怎么流转,其实,他们的基础还是不错的,就是年纪大了,事多,跟不上小年轻学技术,他们pb就得就特熟,数据库优化得比我还好,可是在这样一个讲b/s的年代,他们不得不打上技术落伍的标签,在业务人员面前,抬不起头来,因为,象这些新技术他们确实不怎么懂了,其实oo这样的概念,在业务人员面前算个屁,业务人员只要一套好操作,稳定,符合他们业务的系统,就非常满足了。
其实我自己也很有成就感的,最近一直也在研究MDA,我觉得特定领域的模型驱动还是非常可行的,不要做得太通用,就在一些业务领域,如mis,可以飞快地响应客户的需求,甚至在我们这个项目进行的时候,我们都做到了,上午大家讨论流程和业务,下午和晚上定制系统,第二天一早看效果。
当时客户的业务人员从来还没见过这样开发软件的,因为一般情况下,软件需求要变更,然后再coding,然后再集成测试,然后给业务人员演示的时候bug还不断,还需要一边演示,一边解释,目前正在开发阶段,这是正常的正常的。
到了最后,业务人员提需求,不如我们软件改得快,最后大家都放心了,成,你业务人员就提吧,流程我有流程设计器,表单,我有模型驱动的表单生成,根本就不惧需求的变更。系统也从一个简单的原型开始,一直在变变变。因为系统的设计核心就是面向UI,面向变化,快速需求反应而来的。 3 楼 joyfun 2007-12-21 上次我的其它公司跳槽过来的上司 给我们演示了一个类似的东西
刚开始看的时候还是比较 惊喜.对于业务逻辑比较简单(查询 显示等)可能比较合适 但是一用到复杂的逻辑处理的时候 这样的系统局限性就出来了,关键是开发出适合自己的业务需求的设计器(如果最开始的时候把这个做好了 当然很方便) 但是从头开始的话 意义不大 4 楼 liyong_2003_cn 2007-12-21 joyfun 写道上次我的其它公司跳槽过来的上司 给我们演示了一个类似的东西
刚开始看的时候还是比较 惊喜.对于业务逻辑比较简单(查询 显示等)可能比较合适 但是一用到复杂的逻辑处理的时候 这样的系统局限性就出来了,关键是开发出适合自己的业务需求的设计器(如果最开始的时候把这个做好了 当然很方便) 但是从头开始的话 意义不大
这个跟设计的思路有关系,逻辑处理这一块可以做为一个扩展点,一般mis系统,对于流程、展现(如报表、bi等)、crud、查询、包括权限这一块用得比较多,而逻辑处理一般不是很复杂。对于复杂的逻辑处理,可以扩展出来进行处理,跟业务专家分开,业务专家只提出业务该如何如何实现,由对编程熟悉的程序来实现。
我当时用的是类似于ibatis的方式,由实施人员写sqlmap,因为实施人员对sql比较熟悉,写sqlmap很方便,有复杂的逻辑,他们宁愿写存储过程。不过再做的话,我准备放开成为动态java编译或动态语言之类的扩展点外加上下文管理,这样灵活性就更强了。 5 楼 xiaoxiaodi5834 2007-12-21 这种系统只适用于一些比较简单业务的应用,如果应用于复杂的应用,就跑不下去了。
像CMS之类的完全可以用这种来实现,但是如果真正的业务系统用这个跑起来估计就够呛的。 6 楼 sslaowan 2007-12-21 我那个帖子不是讨论这种简单的mis,而是复杂的生产业务系统,我文中举的OA,跟你说的这个平台差不多,但仅此而已 7 楼 liyong_2003_cn 2007-12-22 我个人觉得,发展通用平台不是个好的方向,要想灵活,哪有编程灵活,要想速度快,哪有特定业务领域的平台开发速度快?中间的是鸡肋