基于
web
应用来说,通常分为三部分:界面层、
业务逻辑层和持久层。在制作
开发平台是,我们都是在这三方面做工作。由于这三层
的特点有些不同,因此我们会采用不同的实现方式来实现。
界面层,强调的是操作界面,因此我们注重采用所见即所得的方式来调整界面布局以及界面样式。更多的我们可以会做一个表单设计器。
业务逻辑层,我们强调逻辑调整的便利性,我们会采用动态语言或者规则引擎来实现逻辑的配置。
在持久层,我们会采用领域模型,根据定义MetaData来定义结构,从而实现和持久层的 访问。当然持久层不全代表是 数据库。
所有的开发平台都是在这三方面做工作,本文主要研究业务逻辑层的实现,我们在国内出现的开发平台中,看到基本都是用代码来实现业务逻辑层的。不过是动态语言还是连接外部 程序。比如工作流中一些前续事件和后续事件等。很少看到采用规则引擎来实现业务逻辑的配置。
究其原因就是基于推理方式的规则引擎并不适合普通业务逻辑的编写。
因此我们需要制作一个不采用推理方式的规则引擎,而采用我们传统的编码逻辑方式的规则引擎。我们可以称之为简单规则引擎。
没有了冲突推理后的规则 系统,将更加简单的来实现业务逻辑。因此其不用再考虑规则优先级,冲突、关联之类的事情,无需再担心某处的一个简单的改变带来了大量无发确定的后果。实现了易用以及灵活性的完
界面层,强调的是操作界面,因此我们注重采用所见即所得的方式来调整界面布局以及界面样式。更多的我们可以会做一个表单设计器。
业务逻辑层,我们强调逻辑调整的便利性,我们会采用动态语言或者规则引擎来实现逻辑的配置。
在持久层,我们会采用领域模型,根据定义MetaData来定义结构,从而实现和持久层的 访问。当然持久层不全代表是 数据库。
所有的开发平台都是在这三方面做工作,本文主要研究业务逻辑层的实现,我们在国内出现的开发平台中,看到基本都是用代码来实现业务逻辑层的。不过是动态语言还是连接外部 程序。比如工作流中一些前续事件和后续事件等。很少看到采用规则引擎来实现业务逻辑的配置。
究其原因就是基于推理方式的规则引擎并不适合普通业务逻辑的编写。
因此我们需要制作一个不采用推理方式的规则引擎,而采用我们传统的编码逻辑方式的规则引擎。我们可以称之为简单规则引擎。
没有了冲突推理后的规则 系统,将更加简单的来实现业务逻辑。因此其不用再考虑规则优先级,冲突、关联之类的事情,无需再担心某处的一个简单的改变带来了大量无发确定的后果。实现了易用以及灵活性的完