请教一个关于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我们都考虑到了，测试代码自动生成。

能提高效率就行！uml不uml都是假的！那种试图提供通用化的能力的，估计都会陷入06z所说的困境中。

你们的模式有一个很大优势：实施人员是客户的信息化部门，而不是客户的业务人员

当时那个项目前期，引擎没有开发出来的时候，客户对我们持相当的怀疑，这是那个项目第三遍在做，以前几百万的投资都打水漂了，前两次的情景历历在目，一堆程序员在coding，当整出个东西来，业务人员就说不行，到了后来，业务人员也不来了，你们自己玩吧，不陪了，所以在我这个项目的初期，我都做好准备了，万一不成功就成仁，虽然我当时有七成把握，但是没见别人做过。
等引擎开发完毕，把信息部门的人给喜得不行,天天加班定制业务,他们很有成就感,因为虽然那些漂亮的UI不是他们自己写出来的,可是那是他们给出的思想,怎么校验,流程怎么流转,其实,他们的基础还是不错的,就是年纪大了,事多,跟不上小年轻学技术,他们pb就得就特熟,数据库优化得比我还好,可是在这样一个讲b/s的年代,他们不得不打上技术落伍的标签,在业务人员面前,抬不起头来,因为,象这些新技术他们确实不怎么懂了,其实oo这样的概念,在业务人员面前算个屁,业务人员只要一套好操作,稳定,符合他们业务的系统,就非常满足了。
其实我自己也很有成就感的，最近一直也在研究MDA，我觉得特定领域的模型驱动还是非常可行的，不要做得太通用，就在一些业务领域，如mis，可以飞快地响应客户的需求，甚至在我们这个项目进行的时候，我们都做到了，上午大家讨论流程和业务，下午和晚上定制系统，第二天一早看效果。
当时客户的业务人员从来还没见过这样开发软件的，因为一般情况下，软件需求要变更，然后再coding，然后再集成测试，然后给业务人员演示的时候bug还不断，还需要一边演示，一边解释，目前正在开发阶段，这是正常的正常的。
到了最后，业务人员提需求，不如我们软件改得快，最后大家都放心了，成，你业务人员就提吧，流程我有流程设计器，表单，我有模型驱动的表单生成，根本就不惧需求的变更。系统也从一个简单的原型开始，一直在变变变。因为系统的设计核心就是面向UI，面向变化，快速需求反应而来的。

上次我的其它公司跳槽过来的上司 给我们演示了一个类似的东西
刚开始看的时候还是比较 惊喜.对于业务逻辑比较简单(查询 显示等)可能比较合适 但是一用到复杂的逻辑处理的时候 这样的系统局限性就出来了,关键是开发出适合自己的业务需求的设计器(如果最开始的时候把这个做好了 当然很方便) 但是从头开始的话 意义不大

这个跟设计的思路有关系,逻辑处理这一块可以做为一个扩展点,一般mis系统,对于流程、展现（如报表、bi等)、crud、查询、包括权限这一块用得比较多，而逻辑处理一般不是很复杂。对于复杂的逻辑处理，可以扩展出来进行处理，跟业务专家分开，业务专家只提出业务该如何如何实现，由对编程熟悉的程序来实现。

我当时用的是类似于ibatis的方式，由实施人员写sqlmap，因为实施人员对sql比较熟悉，写sqlmap很方便，有复杂的逻辑，他们宁愿写存储过程。不过再做的话，我准备放开成为动态java编译或动态语言之类的扩展点外加上下文管理，这样灵活性就更强了。

这种系统只适用于一些比较简单业务的应用，如果应用于复杂的应用，就跑不下去了。
像CMS之类的完全可以用这种来实现，但是如果真正的业务系统用这个跑起来估计就够呛的。

我那个帖子不是讨论这种简单的mis，而是复杂的生产业务系统，我文中举的OA，跟你说的这个平台差不多，但仅此而已

我个人觉得，发展通用平台不是个好的方向，要想灵活，哪有编程灵活，要想速度快，哪有特定业务领域的平台开发速度快？中间的是鸡肋