K2BPM系统开发框架使用说明
合集下载
相关主题
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
2. 需求梳理与确认
用 Viso 等工具划出流程图 用 Axure RP Pro 等工具画出表单原型图。 思考用户提出需求模型是否符合实际业务场景, 是否能够提供更好的改进建议。 另 外 也要考虑当前的技术、人力、时间等制约因素是否会阻碍需求模型的实现。是 否能简化或变更业务模型以避开当前的制约因素;或者将需求拆分,分步骤实施。 用上面画好的流程图和表单原型图和用户确认, 以确认实施人员的想是否和用户的 想法一致。如有不同,修订后和用户再次确认。尽可能提前和最终用户确认他想要 的到底是什么样的东西。
3. 流程设计与开发
根据表单原型图图设计数据库 根据表单原型图图设计程序表单 表单设计初期可以优先完成表单基本功能的制作, 建议不要急着与流程整合, 也不 用考虑表单必填字段与数据类型的验证,能实现增删改查操作即可。 根据流程图设计 K2 流程,注意 K2 流程和业务表单需要交互的数据及时机。 K2 流程设计初期可以只考虑流程步骤(节点)和流转关系,不考虑各步骤有哪些 人及这些人是如何参与到流程中来。 整合流程与表单,进行基本的流程流转测试。 这时可以让最终用户参与进行,确认已实现的流程和表单是否符合需求。 完善表单功细节功能,完善流程各项其它功能。 重新整合流程与表单,进行完善的功能测试。测试主要分两部分:一是表单的完整 性与体验性测试;另一个流程流转过程的测试,这个比较费时间,要尽可能把各种 可能的场景和环节都测试到。
图表 8
排序管理 排序操作主要是通过 Pager 对象上的 SortItems 属性来实现, SortItems 是一个集合, 集合中的元素是 SortItem,SortItem 中包含排序字段和排序方向信息。详情见图表 8 中的示例 C.
2. JS 组件使用说明
此组件存在于 CommonLibrary 项目中,主要封装了表现层(Web)的相关操作,能 将后台的相关命令转换成前台的 Javascript 脚本并执行。 如在表现层 (Web) 的 ASPX 页面中直接调用 UtilityHelper.Web.Alert(this, "保存成功。 ");即可在前台向用户发送一 个提醒窗口,类似 JS 中的 alert("保存成功。");下表列出常用的几个操作。每个操作 可能有多个重载以实现不同需求,详情请看方法的说明。 方法 Alert EvalScript CloseWindow OpenWindow Redirect 说明 弹出一个提未来框架。 执行一段 JS 脚本。 关闭一个窗口。 打开一个窗口。 跳转到指定页面。
b.
扩展数据操作实现
如果上面的通用数据访问类不能满足业务要求,可以通过如下方式来实现自定义操 作(一般只是查询操作) :
图表 6
自定义类继承于 CommonDAL< >泛型类,并指定具体实体类,如 DicTypeEntity。 查询的参数以 SqlParameter 数组的方式传入,多个参数间的以逗号分隔。 执行框架的内置的查询操作,返回 IDataReader 用返回的 IDataReader 的获取实体或实体集合。 如果要返回实体集合,除方法的返回值可替换成List<DicTypeEntity>外,图表 6 中 最后一个红框架内的方法也要替换成 return this.GetList<DicTypeEntity>(reader);
4. 业务逻辑层设计开发(BusinessRole)
图表 7
代码实现要点: 如果是通用操作,只需实例化图表 7 中的第一个红框中的 BasicDAL<>泛型类。 第二个红色模式中自定义操作是扩展查询需要而实现,不是必须的操作。
5. 表现层设计开发(Web)
对于信息系统中常用的增删改查操作, 在框架中一般通过两个页面实现, 我们假设 这两个页面的名字分别为 ObjectList.aspx 和 ObjectEdit.aspx. ObjectList.aspx 页面实现的主要功能有:列表查看,列表排序,分页信息处理,删 除与批量删除操作,新增和删除的导引入口。 ObjectEdit.aspx 主要实现对象新增、编辑和保存操作。 <演示后补充>
三、 业务对象详细说明、
1. DB 表设计说明
目前仅支持 SQL Server 数据库,表字段使用基本的数据类型,尽量不要使用自定 义数据类型。 使用单一主键。可以使用 GUID,字符串,自增长数字作为主键。 数据表和字段有要说明(非强制要求)
2. 实现对象设计开发(Model)
图表 3
属性类上添加以下属性 标识此属性映射至DB中的相关字段,可由框架自动填充数据。 其中FieldName是必填,其它属性为可选值。详细描述请查看 ModelField类和字段的说明。
ModelField
构造函数 详细实现见 图表 4 的红色框内部分。此 方法通过DB查询返回的IDataReader, 自动 向此类上有ModelField标识的属性填充数 据。 其它构造函数不是必须,可根据实际需要 实现。
图表 4
实体类可以通过代码生成器生成。若手工实现,需注意以下几点: 实体类上添加以下属性 Serializable 标识类可以序列化 ModelSelf 标识类映射至 DB 中的相关表,可由框架自动填充数据。其中 TableName 是必填,其它属性为可选值。详细描述请查看 ModelSelf 类和字段的说明。
K2BPM 系统开发框架使用说明
2012-10-16 吴重强
一、 框架描述
二、 架构说明
1. 架构示意图
图表 1
2. 源代码结构
图表 2
项目名称 Model DataAccess BusinessRule Web CommonLibrary
说明 业务实体 数据访问层 业务逻辑层 表现层 公共类库,实现一些通用的方法
说明 向 DB 插入一条记录 更新 DB 中的一条记录 删除 DB 中的一条记录 以实体方式获取 DB 中的一条记录 以实体集合方式获取 DB 中的一批记录 以 DataSet 方式获取 DB 中的一批记录 以 DataTable 方式获取 DB 中的一批记录
以上部分方法有多个重载。实现的功能各不相同,详细信息请查看 BasicDAL 基类 CommonDAL 类的相关说明。 其中分页过滤器 Paper 对象的使用方法和详细供述请查看后续章节。
六、 系统配置
七、 程序引用 八、 流程分析与设计
1. 需求收集
确认用户的组织架构信息与人员信息,这是工作流程系统运行的基石。 尽可能多地收集关于流程方面的信息,如现有的填报表格、公司政策、业务规则、 流程审批需要经过的步骤、参与人员等信息。尤其是政策和规则,一般情况下,用 户很难一次性提供完整的资料,要和用户尤其是最终用户多沟通,多发散思考,尽 可多地去覆盖现实中业务场景。 最好能够确认一些极端场景是否要包含在当前需求 中。 对于审批步骤,要确定哪些是必须步骤,哪些是条件激活步骤。 在每个审批步骤有哪些人参与进来, 是单人参与还是多人会签, 或是多人分捡各自 职责范围内的任务等。 在经过特定的步骤后, 是否要触发其它事件, 如更新外部数据状态, 呼叫其它系统, 发出邮件、短信提醒等。 流程是否有时间方便的要求, 如只能在某时间点后才能进行或在某时间点前必须完 成。
public MenuEntity(IDataReader reader)
其它构造函数
3. 数据访问层设计开发(DataAccess) a. 通用数据访问基类 BasicDAL
通用数据访问已实现如下操作:
图表 5
实现方法 Insert Update Delete Get GetList GetDataSet GetDataTable
四、 流程设计说明
<下次培训内容,稍后补充>
1. DB 设计说明 2. 实体对象设计开发(Model) 3. 业Βιβλιοθήκη Baidu辑层设计开发(BusinessRole) 4. 表现层设计开发(DataAccess) 5. 流程设计开发(Web)
五、 其它说明
1. 分页过滤器(Pager)说明
分页过滤器主要用于系统的表示层向数据访问层传递数据查询的必要信息,数据访 问层将根据分页过滤器提供的描述,自动生成 SQL 查询语句。分页过滤器有三大 功能:分页管理,查询管理,排序管理,详细描述可以查看 Paper 类的相关说明。 下页面对此三个说明 分页管理 分页管理主要通过 Pager 对象上的 Enable,NeedCount,PageSize,CurrentPage 四 个属性来实现分页管理,其它属性由框架自动生成。 查询管理 查 询 操 作 主 要 是 通 过 Pager 对 象 上 的 ConditionCollection 属 性 来 实 现 , ConditionCollection 是一个集合,集合中的元素是 ConditionNode。ConditionNode 是通过名值对来实现筛选的。 能实现如大于、 小于、 等于、 类似于等多种查询模式。 示例见图表 8 中的示例 A 和示例 B。