2.2 流程
2.2.1 经历
工作流程同样是信息管理系统中都会涉及到的，以前开发过的一些项目，几乎每一个都有自己的工作流，例如：文档管理中的文档发布，它涉及到发布、审核、签收，可能还会有审批；车辆管理中申请车辆的流程为申请车辆、批复、派工、归档；还有许多更为复杂的流程，可能有分流、分支、跳转。开发这些项目时，都是根据每个项目流程需求开发流程，因此重用性、灵活性都不好。
2.2.2 想法
在互联网上搜索了一下工作流，发现很多工作流产品，都是收费的，价格也不菲，而且ASP.NET的不多，WWF（微软的工作流，当时还在开发中，没有可参考的文档），于是决定自己开发一套。
2.2.3 实现
根据多年开发项目的经验，将工作流同性的东东抽象出来，下面列出了工作流中一些主要的共有特性，还有各种属性没有在这里一一列出，将在后面的章节中阐述：
Ø 工作流的种类
固定流程：工作单根据事先定义好的流程步骤进行流转；
自由流程：工作单由处理人对下一步的进行控制，传递给指定的处理人或终止该工作单的流转；
自定义流程：工作单由申请人定义流程，工作单根据此流程进行流转。
Ø 工作流流转方式
顺序流转、回传、跳转、在本步骤中继续流转、废止。
Ø 工作流的处理
流程、环节、步骤、分流、分支、处理角色、监控角色及时限。
根据上述共性，本架构中，创建了设置流程的处理类、工作单管理类、工作流的处理接口及抽象类，对于具体的业务流程需要开发人员继承工作流的处理接口及抽象类。
本架构中开发了一个处理表单工作流的功能，许多Web版的办公自动化系统（OA系统）都有基于自定义表单的公文工作流，因此特别开发了这个功能，这个功能包含一个接口、三个类，分别处理固定、自由及自定义表单流程，同时有设计自定义表单等功能。
目前架构中的流程也是支持SqlServer、Oracle、Sybase、MySql及Access等常用的数据库，与系统管理一样通过继承本架构的流程提供程序可添加其他数据库的支持。
2.2.4 图形化
目前还没有时间去做这方面的工作，对于已经有这方面经验的朋友给予支持，使用什么开发流程比较好，SVG？还是 ……
2.3 业务对象
2.3.1 经历
从Dos开发到Windows开发，从快速开发到对象编程，特别是使用对象编程后，与数据库的交互，大多数的类都要编写增删查改的方法，这些方法中都使用了SQL语句，这些SQL语句只是字段名及表名不同，虽然通过一些设计模式减少了工作量，但是仍然有不少的重复工作。目前有许多对象关系映射（ORM）的工具，也曾经使用过（具体的名称已经不记得了），发现不是很适用，（注：当时VS 2008还没有出，Linq还没有见到，而且目前Linq也只是支持SqlServer），于是尝试自己开发自己使用的ORM。
2.3.2 想法
刚开始只是想做一个根据对象的属性自动生成增删查改的SQL语句的基类，开发时就发现对于同时操作多个对象时，很难保证数据的一致性，于是决定增加事务操作。
后来在实际应用中发现开发页面处理时，工作量仍然很大，应该改写页面中经常使用的GridView、ObjectDataSource等控件，将基本一致的操作添加到控件中，以减少页面开发时的工作量。
开发一个业务对象的生成工具，根据数据库的结构自动生成业务对象的代码，减少项目开发时的工作量。
2.3.3 实现
建立一个XML文档，记录业务对象与数据库结构的关系，创建一个类（DataProperty），读取这些关系。
创建一个数据库操作抽象类，根据类（DataProperty）记录的关系及对象的属性值，生成增删查改的标准的SQL语句，并完成增删查改操作，同时该类支持事务操作。每种数据库都有一个具体的操作类，继承于该抽象类，对于该数据库的一些特殊语句，改写抽象类的方法，例如：分页查询的语句各种数据库都不一样，字段类型的赋值也有所不同（datetime类型，SqlServer中用单引号；Access中用#号；Oracle中用to_date函数等等），以实现对各种数据库的支持。
通过业务对象生成工具生成业务对象，根据有页面操作的需要添加一些方法，可以根据业务对象的各个属性的类型自动生成新增、修改及查看页面，字符及数字类型生成TextBox；大文本类型生成MultiTextBox；Boolean类型生成CheckBox；日期类型生成日期控件（根据网上下载的一个开源控件InputCalender改写后的控件，以后的章节中会将该控件的源代码贴出）；选择类型生成Dropdown。
改写ObjectDataSource使它更适应业务对象的查询方法。
改写GridView，添加了新增、删除、编辑、查看以及导出的功能，这些功能页面中不需要有其他代码自动完成，如果不需要自动完成时，都有相应事件。
2.3.4 优缺点
通过ORM架构能快速的搭建项目，极大的减少编程的工作量，我在实际的应用中一个需要一个月的项目基本上一个星期可以完成，而且项目的出错机率也相对减少，需求变动后的改动量也很小。我在开发系统管理架构时，不想与ORM有紧密的耦合，别人在不想使用ORM架构时也能使用系统管理架构，因此专门有一个SQL语句的管理类，负责提供SQL语句，在这个类中有上百条的SQL语句，在开发流程架构时，由于数据表过多（有三十多个）决定采用ORM架构，编程的工作量明显减少。
但是与其他的ORM一样，存在性能的问题，业务对象的属性值需要经过多少装箱及拆箱，以及需要读取XML文档的信息，同时在页面处理时用了反射，这些都是影响速度的，对于小型项目我想以目前服务器的性能不会产生太大的影响，但是对于中大型项目，影响肯定有，只是说有多大，目前没有测试过，希望有这方面经验的朋友能发表一下意见。
说了这么多泛泛而谈的东东，可能许多人已经厌烦了，下面将开始说架构实现了，请朋友们多多评论，对于有更好的设计也希望讲解一二。