如此的框架设计，如何实现！

等了三天，终于可以发帖子了，
我的总监（不懂java和面向对象编程）有自己的一套设计思想，让我来实现，极度郁闷中，请大家给点建议！
设计思想：
1、目标：在以后的项目中不再编码，将所有的页面、工作流、业务逻辑、sql语句等都通过自己编写的图形化工具实现配置，程序员不再编码就可以完成项目的实施工作。需要编写页面定制器、页面验证组件、工作流图形化工具、业务逻辑解析器、持久化组件等。
2、因为我们的项目中大量使用了流程，所以要求编写工作流引擎（已基本完成）、规则引擎等，但老板要求在工作流流转的过程中所有的业务数据不持久化到数据库中，而是将每一个节点中的业务数据都存放到hashmap对象中，当节点发生变化时将hashmap对象存放到数据库中；每次执行流程中的待作任务时要将hashmap对象恢复，然后在向hashmap对象中添加数据，直到所有流程结束后在将hashmap对象中的数据写到相应的数据库表中。

我想问如果采用此方式实现，会不会有效率问题，是否能够实现？

这种框架，可以称之为“Over型框架”，有了它，软件开发就进入了共产主义。

这是一种伟大理想，你去努力实现它，就会在实现它之前死掉！

当然没问题，MDA就是做这样的事情的。你们也做一个吧。


在运行过程中服务器崩溃怎么办

想要一点编码都不用，基本上不可能。

如果作代码生成的东西，首先要定制规则。

所有的层，界面，等等，都需要先定好规则

这不但是可能的，而且已经发生在7年前，不但发生了，而且就在我的眼皮底下，不但在我的眼皮底下，而且至少有50-100个企业在用这套软件，其中有很多是比较大的企业。软件至少在浙江省还是很有名气的。

但是这也会带来很多很多的问题，总的来说，当软件所需要解决的问题发展到一定的复杂性以后，成本并没有象原先预期的那么下降，而是提高

我其实在几年前就总结过了这种做法的优缺点和相应的改良方案，我也在很多地方和不少人提到。但是一个公司的主导产品的改变不单单是技术问题，还有观念、投资等等，所以现在还继续在发展，虽然我已经离开很久了。

而根据我接触过的很多软件企业老总（甚至包括很多技术负责人）来看，这还是其中大部分人的梦想。

to potian：
如果实现需要多大的人力、物力的投资

to 冰云 努力成为架构师：
我们现在所要考虑的就是如何确定规则，以及解析规则，这也是我现在最头疼的问题。


to jinbo：
如果服务器崩溃，只有将当前节点中所作的工作重新再作一边了。

首先，我建议你不要去实现。这也是我为什么自信对MDA看法没错的原因之一。

我把大体的结构描述一下，你自己估估看
首先，鉴于这个系统从96年左右就开始开发，这是一个纯粹基于关系模型的系统，下面所有的描述都是基于这一点的。由于商业上的问题，我的叙述从简，并且把一些系统里面的术语统统简化为关系词汇。

一个企业应用系统一般来说需要几个要素：
数据存储

1 关系成分的定义：如何定义数据库结构和数据表，这个系统中，所有的表都是从头开始的，也就是说，你可以新建、修改一个表，这个表中的所有meta信息，包括所有字段、类型、约束都是可以定义的，并且不需要代码生成
2 关系成分之间的关系定义：总的来讲，当初设计的时候解决几类关系，所谓的参考数据，实际上是n:1，例如产品类型拉等等，以及父子表，即1:n,附表关系也就是1：1，父子孙关系，是1:n*1:n的关系，在这个系统中允许存在的最复杂的模型是1个表有一个附表，一个从表和一个孙表
3 对关系模型的支持：定义好了表之间的关系，我们可以定义各种表之间的关系，这种关系通过定义好的OID进行关联，在界面上互动（等一下回讲到界面的设计），当主表发生变化的时候，包括新增记录、删除记录、修改记录，所有地从表和附表都会得到通知，相反也是一样的。发生通知的时候可以出发一系列动作，这些动作可以是一个存储过程，一个插件，当通常是一段脚本（等下详述），这个脚本可以用手写，但最普通的情况是可以在系统的GUI设计街面上选择中文的表名和字段，脚本支持各种函数的定义，等等。系统为这些脚本定义了一个上下文，譬如当前的记录等等，因此不需要进行查询，有点类似于Class.this，但又不需要明确指定。

-----
等下继续，如果有兴趣

如果这样存储的话，那要针对尚未结束的流程进行查询就无法用SQL语句了，效率应该会比较低吧。不在流转过程中直接持久化是出于什么考虑？