《生产流水线模式》-也谈如何实现从数据库到UI的一条龙服务
今天看到金色海洋的《超级传送带-我的程序思路》,以及亚历山大同志的《如何使用系统数据库》,不由得深有感触,如骨鲠在喉,不妨探讨一下从数据库到UI的一条龙服务是不是可行?
从根本上来说,任何一个项目都可以分为以下三个过程
(1) I(Input):即输入数据,包括用户使用各种表单录入数据,导入数据等等。
(2)P(Process) :即数据处理,对数据流的控制(Data Flow),其中包括,在数据保存到表中之后要进行相应的更新动作。例如:库存数据的计算,会计凭证的月份结转等等
(3)O(Output) :即结果输出,分析报表,一般的查询报表等。
长期以来,采用三层结构模式开发的Web项目,可以说I(数据输入)和O(结果输出)的部分要占到80%以上,大量重复而烦琐的工作都是:前台页面、界面排列、新增、删除、修改、查询。这些工作必须编写程序代码来实现。因为编写程序代码不直观、可读性极差、不易与非专业人员沟通、代码编写周期长、不能重复使用、不易修改优化。技术含量低,而且繁琐、冗杂,可维护性差,占用了大量的开发资源,甚至影响了项目进度。
如果换一个思路,暂不考虑对数据处理流程(不同业务的数据处理流程很难用一个规范的模型来进行描述)。上述工作无非就是:
(1) 数据从何而来;比如数据是存储于数据库的那张表;
(2) 数据是什么样的:数据的组成字段、格式等等;
(3) 数据如何进行表现:具体来说,就是什么样数据用什么样格式(控件)来获得,展示。
(4) 怎样从用户输入的表单中,提取相应的数据字段,并回写到数据库或者数据源。
很明显,上述过程完全可以用程序来自动实现,无非就是将相关的参数输入数据库,而应用程序读取这些参数以后,自动生成相关的程序对象,进而实现传统手工编码程序完成的工作。这也就是系统架构中,对象层所完成的工作。
在此,我认为金色海洋所提出《超级传送带》的说法未免显得过于简单和偏僻,也许以《生产流水线》更为合适。那么这条《生产流水线》的工作过程是什么样的?
(1) 数据库设计:根据需求分享,完成系统的数据库设计。
(2) 生成数据实体对象:从数据库中读取相应的数据表结构、字段等元数据,以此生成相应的数据对象。
(3) 配置数据实体对象的相关属性:比如数据对象的权限。查询等等属性的设置。
(4) 生成用户自定义表单:提供用户表单设计器,让用户输入Html格式的表单,将数据对象与表单绑定,在表单上放置相应的控件,设置控件的属性、数据绑定字段等等,
(5) 设置系统相关属性:菜单、数据列表窗体等等。
(6) 系统运行!
至此,很多人就会提出问题:“虽然能够提高开发速度,但充其量只能适应部分系统的开发,要完全适应各种开发需求恐怕是不可能的”、“复杂的业务逻辑如何实现”等等。
在我看来,这些问题和担心实在很搞笑!!为什么这样说呢?大家不难看出,此系统的核心部分是生成的各个数据实体对象,相应生成数据实体的代码如下:
IDataEntityProvider currentObject = null;
lock (thisLock)
{
if (this.dbEntityCache.ContainsKey(name))
dbEntityCache.Remove(name);
object[] args = new object[] { name};
Object.ObjectEntity currentDomin = Object.ObjectHandler.Current[name];
if (currentDomin != null && currentDomin.ObjectType != null)
{
currentObject = (IDataEntityProvider)Activator.CreateInstance(currentDomin.ObjectType, args);
currentObject.DataAccess = DataAccess.DriverManager.Current.GetDriver(name);
this.dbEntityCache.Add(name, currentObject);
}
}
数据实体对象只要求实现IDataEntityProvider 接口即可,至于对象是由系统自动生成的,还是由我们编写代码实现的,并无特别的要求和限制。因此,如果对象有复杂的业务逻辑要求,当然可以编写代码实现,加入各种业务逻辑处理。
当然,我们可以首先定义一个基类,实现IDataEntityProvider接口。有需要实现特定业务逻辑的数据对象时,继承该基类,编写业务逻辑代码即可。这和常用的业务逻辑层编写没有任何区别。
这种开发模式的优点在于:
(1) 开发工作量和周期的锐减,比如,传统开发,要建立一个Web页面录入显示数据,一个熟练的程序员需要几个小时,用这种模式大概十分钟就够了。
(2) 维护、更新工作的简化,比如,数据库表增加了一个字段,只需要重新读入表结构,修改数据实体对象的设置,表单的绑定字段即可,所有的工作完全可以通过维护界面进行,无需编码;
(3) 开发文档的简化,很容易将对象参数提取形成文档,减少了工作量。
当然,要实现这样一条《生产流水线》,其工作量也是相当的惊人,我们也是经过了多年的开发、项目实践、改进才达到比较理想的效果。而且这样一个架构也不能实现系统分析、设计、业务逻辑处理等等工作。
我们使用该架构已经完成了很多项目的开发,目前还没有商业化、或者是开源的计划,在此,只是简单阐述一下设计思路而已,以说明从数据库到UI的一条龙服务是完全可以实现的。所以,没有效果图(以避免做广告的嫌疑)、没有源代码下载。