2008年8月19日
#
我的上一篇文章《生产流水线模式》发布以后，引起了很多朋友的关注，大家发表了很多意见，现在我针对留言中大家提得比较多的问题，做一个总结性的回复。
问题一：我的敏捷开发架构是不是只实现了简单的增删改查功能？无法适应复杂的业务需求？
回答：当然不是，正如我在上篇文章所提出的：定义一个基类，实现IDataEntityProvider接口、实现对数据的增删查改功能。当有需要实现特定业务逻辑的数据对象时，继承该基类，编写业务逻辑代码即可。
除此之外，还通过更为简洁的方式：利用注册事件，类似于数据库触发器，来处理业务逻辑，比如：
public virtual void Save(DataRow[] Rows)
{
if (this.Trigger != null)
{
this.Trigger.OnSaving(this, Rows);
}
DataAccess.Update(Rows);
if (this.Trigger != null)
{
this.Trigger.OnSaved(this, Rows);
}
}
触发器的代码：
public void OnSaved(ObjectService.IDataEntityProvider dataEntity, System.Data.DataRow[] rows)
{
if (dataEntity is IGetMarker)
{
foreach (DataRow row in rows)
{
MarkerEntity markEntity = ((IGetMarker)dataEntity).GetMarker(row);
MarkerHandler.Current.Update(dataEntity.TableName, markEntity);
}
}
}
采用注册事件，在数据对象进行增删查改的操作同时，触发器完全可以实现对复杂业务的逻辑处理。举个例子，使用这种方式，我们实现了WWF工作流的封装，最终用户可以用浏览器实现工作流程、工作流表单、以及相应业务逻辑的设计，而这一切都不需要写一行代码。
问题二：这样的敏捷开发架构究竟有多少实际应用价值？
回答：
（1） 需求调研阶段：快速构建系统原型。
这个构建速度有多快呢？比如，有朋友在留言中说到，在充分调研的基础上，用一个月的时间来实现系统原型。如果换成我的话，不夸张地说，三天足矣。再具体一点，在实际项目开发中，很多用户往往会拿出一个Word、Excel表单，要求我们用程序实现，那么，只需要一个小时，我们就可以实现从建表到程序运行。
至于快速构建系统原型的价值，想必大家都非常清楚，除了一个马上可以运行的系统，还有什么办法，更能让用户更为踏实，更愿意沟通呢？
（2） 设计实施阶段
一般来说，好的设计应该是容易实现的。但是再好的设计也需要编码实现，如果能通过一系列的参数设置，简单设计一下表单就能够将系统80％的工作完成，这样一来，系统设计实施的效率不就成倍地提升了吗？项目中宝贵的时间精力就可以集中到业务核心问题的解决上了。
举几个项目开发中的例子：
l 部队政工管理系统：客户在滇西，交到我手上的只是40多页的政工档案表格，以及一个部门机构设置图，数据处理不复杂，主要是权限要求很罗嗦，要求到达何种级别、职务部门的可以发何种文件，可以审阅、可以查看等等。用了一个星期完成系统，发布在服务器上，让用户试用、提意见、修改，全部完成用了两个月的时间。
l 由两个刚毕业学生完成的政府部门MIS系统，包括公文、常住人口、暂住人口、计生、党建、文档管理等等，两个学生没写一行代码完成。
l 酒吧管理系统：对酒吧的人、财、物、进、销、存进行管理，涵盖从老板、经理、领班、服务生、妈咪、小姐、酒水、包房、台、会员卡等等。对方是一家专业的酒吧管理公司，用过多套酒吧管理软件，都不满意，这次由他们自己提出详细需求，由我们来实现的。
2008年8月17日
#
今天看到金色海洋的《超级传送带－我的程序思路》，以及亚历山大同志的《如何使用系统数据库》，不由得深有感触，如骨鲠在喉，不妨探讨一下从数据库到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的一条龙服务是完全可以实现的。所以，没有效果图（以避免做广告的嫌疑）、没有源代码下载。
2008年5月29日
#
去年11月份，本人发表了关于敏捷开发的系列文章，就一直没有下文了，还被很多朋友抱怨了一番。真实情况是，从去年年底开始，本人开始做手机旅游地图的项目，后来得到一笔投资，成立了公司。程序开发不再是主业，请大家原谅。
虽然本人不再以程序开发为主，但有时间精力的时候，还是对敏捷开发平台进行不断的修改完善，也以这个平台为基础，陆续完成了一些项目。那今天为什么要写文章推荐这个应用系统呢？因为这个系统的全部开发工作都不是我做的！
系统的演示地址：http://61.166.111.222/NS/Default.aspx,
用户名：SystemAdmin，
口令： 123456。
首先简单介绍一下情况，承接这个系统开发的公司是朋友的，因为公司的主业不是做软件开发的（当然专业做软件开发的公司现在也很少了），招聘专门的程序员来做也不现实。最后只是招聘两个今年刚毕业的学生来做这块业务。当初，请我去帮忙带一下他们，我用来大概两个星期的时间，带这两个学生完成一个系统以后就离开了，后面承接的这个系统就是他们独立完成的。
带他们的时候，时间比较紧张，只是把从需求分析、设计，以及使用敏捷开发平台进行开发的大致过程讲了一下，差不多是手把手地教了一遍从数据库建表、设计对象、设计表单的全过程，对C#的语言、编程等等让他们自学。
这个系统有11个模块，三十多张数据表，我只是在收集原始资料做需求的时候指导了他们一下，后续的开发工作都是他们自己完成的，大概是用了三个星期的时间。现在交付给客户使用，客户反应很不错。
在此，我不想讨论系统的技术怎么样。我想强调的重点是：这个项目开发不需要编码，不需要AJAX ，不需要 面向对象 等等，他们只是建了一系列的数据表、做了几个Html的页面就完成了系统开发。
大家可以自行评估一下，如果是自己开发，需要多少时间和人力，
顺便说一下，他们现在的工资还是1k多，离开了敏捷开发平台，他们还是只能做些简单的网站。
2007年11月9日
#
2007年11月2日
#
近几年我一直从事于Web应用系统架构的研究和项目开发，传统Asp.net开发模式存在的种种弊端，对程序员的水平要求很高，导致项目开发、维护成本居高不下，严重制约公司发展。所以，从去年开始，我们开始致力于研究开发Web敏捷开发平台－e联在线系统，经过近两年的各种项目开发实践，该系统已经相当完善稳定，并作为一个商品化的开发平台推向市场。在此，我开始撰写该平台的系列介绍文章，和广大同仁分享，来探讨Web系统的敏捷开发模式。
《e联在线系统》是一个完整的Web应用系统架构，包括如下组成部分：
l “即插即用”、无需编码即可实现的数据实体；
l 在线编辑、在线发布的Web表单；
l 集成WWF工作流引擎；
l 完整集成了菜单、导航、工具栏、数据列表、弹出窗体等等常用的UI控件；
l 组织机构、用户角色权限控制；
l 自动实现的AJAX框架。
e联在线系统基于元数据模型驱动架构的设计模式，通过元数据来保存数据实体、Web表单、用户界面和工作流的模型，运行时系统框架加载元数据模型，自动创建相应的数据实体对象、表单对象、界面对象和工作流对象，以实现访问数据、创建表单、加载界面和启动业务流程。
传统开发模式，要实现对象功能必须进行编码，由于编写程序代码不直观、可读性极差、不易与非专业人员沟通、代码编写周期长、不能重复使用、不易修改优化。技术含量低，而且繁琐、冗杂，可维护性差，占用了大量的开发资源，甚至影响了项目进度。
采用元数据模型驱动架构的开发模式，实现对象功能只取决于赋予对象的元数据，也就意味着在成熟稳定的系统架构下进行开发，开发人员将从繁琐、冗杂的重复编码工作中解脱出来，将主要的精力集中于业务功能的实现上，从而使项目开发过程发生根本的改变。
在开始介绍 《e联在线系统》之前，我先介绍一个由系统实现的网上订单模块，让大家对系统有一个直观的了解。
l 网上订单需求定义
（1） 经销商输入订单、选择产品，提交到商务部门。
（2） 提交的订单，由商务主管、财务主管共同审核，需两者都同意后，才能发货，否则将订单返回经销商。
（3） 经销商可查看提交的订单执行情况。
（4） 正在执行的订单、成功执行的订单不能进行修改，作废的订单可以由管理员删除。
l 开发说明
（1） 所有的界面、表单、工作流程，均为输入参数后，由系统自动生成，没有一行编码。
（2） 用户需求变动时，无论是添加数据库字段、改动界面和表单，修改工作流程，都只需要调整相应参数，由系统自动生成对象即可，实现“即时修改、即时使用”。
以上Demo在网上有演示地址，感兴趣的同仁可以加入QQ群：C#敏捷开发（49562598），或者发邮件到 ynfengjun@Gmail.com,获得演示地址和用户帐号。
接下来的文章，我将开始详细介绍《e联在线系统》的系统架构。功能和设计理念，将请关注。
2007年3月22日
#
项目开发无非分为以下三个过程
（1) I(Input)：即数据输入，就是我们的数据录入程序，如：客户数据维护，厂商资料维护等等
（2）P(Process) ：即数据处理，对数据流的控制（Data Flow），其中包括，在数据保存到表中之后要进行相应的更新动作。例如：库存数据的计算，会计凭证的月份结转等等
（3）O(Output) ：即结果输出，分析报表，一般的查询报表等。
总结项目开发的全过程，数据输入和结果输出的部分占大约95%的工作，而且都是进行如：前台计算、界面排列、新增、删除、修改、查询的工作。
长期以来，这些工作必须编写程序代码来实现。因为编写程序代码不直观、可读性极差、不易与专业人员沟通、代码编写周期长、不能重复使用、不易修改优化。技术含量低，而且繁琐、冗杂，可维护性差，占用了大量的开发资源，甚至影响了项目进度。
你是否有过这样的经历：
l 客户的需求反复无常，变来变去，一个字段、一个标签不对，也要叫你马上改出来。
l 前任留下大堆大堆的程序，没有文档、没有注释，开发变成了考古；
l 老板告诉你一个好消息，客户已经决定采购我们的产品了，不过嘛，他们要求做一些特殊的修改，也就改七、八个页面，明天就要，你辛苦一下，加加班？
怎么办？经过申诉、抗议、讨价还价。。。。（省去 xxx 字），开工吧，等你噼噼啪啪地把代码敲完的时候，好像同事已经来上班了，头发又白了几根。。。。
也许，在开始敲键盘之前，我们要停下来，好好想一想：
编写代码是必须的吗？