今天看到金色海洋的《超级传送带－我的程序思路》，以及亚历山大同志的《如何使用系统数据库》，不由得深有感触，如骨鲠在喉，不妨探讨一下从数据库到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
{
if (this.dbEntityCache.ContainsKey(name))
dbEntityCache.Remove(name);
object[] args = new object[] { name};
ObjectEntity currentDomin = Object.ObjectHandler.Current[name];
if (currentDomin != null && currentDomin.ObjectType != null)
{
IDataEntityProvider)Activator.CreateInstance(currentDomin.ObjectType, args);
DriverManager.Current.GetDriver(name);
this.dbEntityCache.Add(name, currentObject);
}
}
数据实体对象只要求实现IDataEntityProvider 接口即可，至于对象是由系统自动生成的，还是由我们编写代码实现的，并无特别的要求和限制。因此，如果对象有复杂的业务逻辑要求，当然可以编写代码实现，加入各种业务逻辑处理。
当然，我们可以首先定义一个基类，实现IDataEntityProvider接口。有需要实现特定业务逻辑的数据对象时，继承该基类，编写业务逻辑代码即可。这和常用的业务逻辑层编写没有任何区别。
这种开发模式的优点在于：
（1） 开发工作量和周期的锐减，比如，传统开发，要建立一个Web页面录入显示数据，一个熟练的程序员需要几个小时，用这种模式大概十分钟就够了。
（2） 维护、更新工作的简化，比如，数据库表增加了一个字段，只需要重新读入表结构，修改数据实体对象的设置，表单的绑定字段即可，所有的工作完全可以通过维护界面进行，无需编码；
（3） 开发文档的简化，很容易将对象参数提取形成文档，减少了工作量。
当然，要实现这样一条《生产流水线》，其工作量也是相当的惊人，我们也是经过了多年的开发、项目实践、改进才达到比较理想的效果。而且这样一个架构也不能实现系统分析、设计、业务逻辑处理等等工作。
我们使用该架构已经完成了很多项目的开发，目前还没有商业化、或者是开源的计划，在此，只是简单阐述一下设计思路而已，以说明从数据库到UI的一条龙服务是完全可以实现的。所以，没有效果图（以避免做广告的嫌疑）、没有源代码下载。
