实例介绍
【实例简介】
用友T+二次开发说明文档,PDF格式，带示例说明
用反软件 1.变更说明 日前的T+平台在不断的完善过程中,因此T+产品开发过程也会不断变化。下面的表单 用于详细记录本开发手册变更过程。 序 变更位置 变更内容说明 变更人变更日期 23456789 2.引言 编写目的 随着T+产品业务的不断扩大,个性化需求越来趁多。如何能够让其他人员利用T+平台 进行个性化开发是要面临的重要问题。同时,随着T+产品开发人员流动,如何降低新员工 学习成木,更快的融入廾发团队,也是亟待解决的问题。为解决以上问题,急需一个成熟的 开发手册。为此,撰写此T+产品开发手册。 名词术语说明 在开发描述中会涉及到一些迸用的名词术语,为便于阅读者理解,对这些名词术语进行 进步说明。具体说明如下 序号 名称术语 详细描述 变更日期 1234567 令用友软件 参考资料 3.开发模型 拓扑模型 道数据库服务器通应用服务器 移动PC Intranet 通We服务器疠火清 Web客户端 Web客户端 Web客广端 PDA 此系统是一个B/S架构的产品,服务器集中部暑。在内部局域网中,用户可以通过浏览 器直接访问WB服务器;其它受管辖的局域网也可以通过专网访问内网中WEB服务器;另 外 Internet用户可以跨越防火墙,通过代理服务器进行业务操作ε 为了提高性能,我们可以把web服务器与应用服务部署在一台服务器上,减少不必要的 远程调用;如果用户想要把wb服务器与应用服务器进行物理上的分离部暑,我们的应用框 架也支持这种部暑,并且我们采用htp的传输协议 此系统架构中,采用后台提供服务的架构设计,降低产品中各模块的偶合度 逻辑模型 4 用反软件 Broswer Web server Applicatlon Server (Is) DB Server (SQLServer) Business entity Paster tate wester gete Ajax Procurement Framework 5 U件 E weary qUIC) Server Silverlight Cash Banking Cash Banki U处理组件 UIP) Business Applieation Platform Technology Platform 上面所式三层服务体系结构基本上是一个松散的三层体系结构。三层分别是 表示层。表示层提供应用程序的用户界面(UI),处理用户和软件间的交互。主要职责 是向用户显示信息并把从用户获取的信息解释成业务层或者数据源层的各种动作。 业务层。业务层实现应用程序的业务逻辑:根据输入或者已有的数据进行计算,对从表 现层输入的数据进行验证,处理从ξ现层接受到的命令来确定应该调用那些数据源逻辑。。 数据源层。数据层提供对外部系统(如数据库、和其它系统提供的服务)的访问 每一层应当按下面各段落所述进行构造 表示层: 包括一系列与用户交互的窗体(或面)。每个窗体用来显示系统提供的信息以及传递 用户的输入信息。这种基于窗体的用户界面包括两种类型的组件: 用户界面组件(UI) 基于. NET Framework提供的组件,包括 Win form组件和 Web form组件。第 三方提供的组件和平台开发的组件。例如:单据、参照、单据列表组件等。 用户界面处理组件(UP) 复杂的用户界面通常需要很多非常复杂的窗体。为了提高其可复用性、可维护 性和可扩展性,需要创建一个分离用户界面处理的组件,以封装窗体和界面导航之 间的相关逻辑。可以对一个简单窗体中组件之间的依赖、确认和导航应用相冋的概 念 业务层 大型的企业级应用通常围绕业务组件和业务过程进行杓造。这些通常以业务层的很多组件、实体 代理和接凵展现出来。 业务对象:业务对象封装一个业务中的元数据、存储、并发和一件事物的业务规则、过程或 事件。多个独立的但有关联关系的业务对象可以一起协作来完成一个应用。完成不 令用友软件 同的任务需执行很多貝有不同特点的业务对象。业务对象负责执行包括强訇的业务 规则、应用规则、数据有效性、并发和存储等所有方面的内容。业务实体对象是业 务中实际存在的事物或概念,是对“ER”模型中概念的面向对象的扩展。 业务处理对象:描述贯穿业务的工作流程和信息。这些处理驱动业务实体完成业务功能。业 务处理对象叮能由工作流系统、业箦对象管珄器、面向对象语言、程序语言、或交 互过程定义系统实现。通过调度一个或多个业务对象实现业务处理。业务处理可以 作为对象的一部分在内部完成。 服务接口 个应用可能会以服务的方式提供一些功能供其它应用使用。服务接口代表这种对外 的服。它隐臧了实现细节,只提供必要的业务接口。 表小和业务的调用:业务层的调用服务通过平台提供的服务工厂来实现。这样有 利于次开发服务能够动态的护展到应用程序中去 数据层 业竻应用必颁访问存储在数握库中的数据。这些数据库通常是关系数据库。数据访问组件负责访 问存储在这些数据库中的数据,并与业务层进行交互。 数据访问组件隔离业务层和数据存储管理。这种隔离有以下好处 减少数据库提供者变更带来的影响 减少因数据对象变更带来的影响(如变更数据厍的 —封装数据的处理操作,这将在很大程庋上减少测试和维护作: 通过平台提供的数据访问服务组件管理 的复杂度,同时能够再不改变表现层和业务 层的情况下来转换不冋的数据库。 实体数据传递— ntityData 在服务器端和应用服务器端通讯或应用之间通讯时,我们采用粗粒度的服务,使用 来传递数据。在设计时,我们将为每一个实体类自动产生一个 数据类,该类中包 含与实体相同的属性。在前端可以使用数据类,但不能使用实体类。 服务网关 业务组件经常必须访问内部或外部的服务或应用。一个服务网关是封装了接口、协议和使用这种服务 的代码的组件。服务网关可以模拟外部服务促进领域测试。 技术平台(BAP): 基础引擎:服务总线, 系统日志,事务、缓存 认证、安全等内空, 基础组件和模版组件,工作流,数据交换 业务平台(BAP):根据小企业的特点定业业务模式框架 6 用反软件 物理模型 客户端(浏览器) Http Web服务器 应用服务器 21议 UIC LIP Https协议 Service Interfa EAP 数据库服务器 用户界面组件(UIC)和用户界面进程组件(UIP),和业务层接口( Inter face)是对 Internet公开的,并且可能潜在地与许多客户端交互。由于这些表示层组件通常公开于公 司防火墙外部,因此其安全要求通常比未公开的组件具有多得多的限制。此外,许多组织要 求公开于 Interne中的服务器不能包含任何敏感数据。因此,通过将表小层组件单独放入 级并配置该级使其具有最高安全性,可显著提高解决方案的总体安全性,同时可尽量降低 对安全性要求相对较低的组件的影响 山于表示层组件公开于 Internet中,因此其性能和可伸缩性要求通常不同于域和数据 访问层组件的性能和可伸缩性要求。表示层组件通常为处理以突发方式与组件父互的许多并 发用户而进行优化。域和数据访问层组件通常为处理来自相对较少的源所发出的稳定请求流 而进行优化。配置一个可充分支持这两组优化的级可能是非常困难的。因此,解决方案是使 用两级,并使每层针对所驻留的组件类型进行优化 部署路径 扩展纬度+核心应用层 App扩展层 逻辑纬度 Core Extends WEB服务器 FSmart/&Version/Website UFSmart/Version 令用友软件 Website/extend 应用服务器 UFSmart/&Version /App Server UFSmart/Version AppServer/ Entends 数据库服务器 UFSmart/ &Version/ Database UFSmart/& Version Database/Extends 说明:其中& Version版本代表本版要发版的版本标识 4.SDK应用开发 开发环境准备 4.1.1.硬件配置 建议配置信息如下: CPU:双核主频20以上 内存:DR2,2G以上 硬盘:普通SCSⅠ(或SAS)硬盘,磁盘柊式为NTFS容量磁盘剩余空间10G以上 4.1.2.软件配置 建议配置如下: 数据库 操作系统 开发工具 MSSQLServer2005及以| Windows XP、 Window7、 上 Window8、 indow203V2010及以上 Window 2008 4.1.3.SDK包 T+提供相应的开发包 4.1.4.开发规范 开发限制,在后续中逐步完善 用反软件 应用场景开发 格式说明 1、依赖动态库 2、实现接凵 3、配置文件 4、案例 4.2.1.开发表单 基础设置列表及表单开发 4.2.1.1.1.应用场景 在现有T产品中,往往有这种应用场景:对某个业务表以列衣的形式展示处理,并能 对这个业务表进行増、删、改操作。像T+产品中的基础设置下的仓库、业务类型档案的实 现如下: 1、进入档案,展小出档案列表信息界面 首页化导航位库业务类型 新増修改删除栏目扩退出 序号 仓库码 库名称 车也址 鱼查人参与可用且注月 是 是 是 2、新増、修改后进入档案编辑昪面 令用友软件 首页 库业务类型 新怕 退H 仓奉地址负责人库一阿夏话 □厂 上张下张保存保存新没置且的 a lLy://lueallusL: <n00,heUsiLe/DATTLuw/Tss 仓车地 负责 年最 用 loc alhost: 4708 Yebs: te, BAFView/B=3*tt Irtreet 3、保存后退岀,返回到列表,并把新增内容展示在列表咔 首页初始化导就仓库业务类型 新增 册除栏目打印出 序号厂仓库编码仓库名称仓库地址负责人参与可用量停用 否 针对此种场景,我们进行了归纳总结,提供了总体实现方案。 4.2.1.1.2.设计思路 这种场景主要依赖于三个组件:按钮组件、栏目组件和单据组件。通过对场景分析,抽 取岀公共的特性进行分析,规范场景处理流程。对于个性化需求,通过提供扩建接口的方式 来实现。 4.2.1.1.3.应用举例 现在以一个实例讲述这个场景的开发过程 10 【实例截图】
【核心代码】
用友T+二次开发说明文档,PDF格式，带示例说明
用反软件 1.变更说明 日前的T+平台在不断的完善过程中,因此T+产品开发过程也会不断变化。下面的表单 用于详细记录本开发手册变更过程。 序 变更位置 变更内容说明 变更人变更日期 23456789 2.引言 编写目的 随着T+产品业务的不断扩大,个性化需求越来趁多。如何能够让其他人员利用T+平台 进行个性化开发是要面临的重要问题。同时,随着T+产品开发人员流动,如何降低新员工 学习成木,更快的融入廾发团队,也是亟待解决的问题。为解决以上问题,急需一个成熟的 开发手册。为此,撰写此T+产品开发手册。 名词术语说明 在开发描述中会涉及到一些迸用的名词术语,为便于阅读者理解,对这些名词术语进行 进步说明。具体说明如下 序号 名称术语 详细描述 变更日期 1234567 令用友软件 参考资料 3.开发模型 拓扑模型 道数据库服务器通应用服务器 移动PC Intranet 通We服务器疠火清 Web客户端 Web客户端 Web客广端 PDA 此系统是一个B/S架构的产品,服务器集中部暑。在内部局域网中,用户可以通过浏览 器直接访问WB服务器;其它受管辖的局域网也可以通过专网访问内网中WEB服务器;另 外 Internet用户可以跨越防火墙,通过代理服务器进行业务操作ε 为了提高性能,我们可以把web服务器与应用服务部署在一台服务器上,减少不必要的 远程调用;如果用户想要把wb服务器与应用服务器进行物理上的分离部暑,我们的应用框 架也支持这种部暑,并且我们采用htp的传输协议 此系统架构中,采用后台提供服务的架构设计,降低产品中各模块的偶合度 逻辑模型 4 用反软件 Broswer Web server Applicatlon Server (Is) DB Server (SQLServer) Business entity Paster tate wester gete Ajax Procurement Framework 5 U件 E weary qUIC) Server Silverlight Cash Banking Cash Banki U处理组件 UIP) Business Applieation Platform Technology Platform 上面所式三层服务体系结构基本上是一个松散的三层体系结构。三层分别是 表示层。表示层提供应用程序的用户界面(UI),处理用户和软件间的交互。主要职责 是向用户显示信息并把从用户获取的信息解释成业务层或者数据源层的各种动作。 业务层。业务层实现应用程序的业务逻辑:根据输入或者已有的数据进行计算,对从表 现层输入的数据进行验证,处理从ξ现层接受到的命令来确定应该调用那些数据源逻辑。。 数据源层。数据层提供对外部系统(如数据库、和其它系统提供的服务)的访问 每一层应当按下面各段落所述进行构造 表示层: 包括一系列与用户交互的窗体(或面)。每个窗体用来显示系统提供的信息以及传递 用户的输入信息。这种基于窗体的用户界面包括两种类型的组件: 用户界面组件(UI) 基于. NET Framework提供的组件,包括 Win form组件和 Web form组件。第 三方提供的组件和平台开发的组件。例如:单据、参照、单据列表组件等。 用户界面处理组件(UP) 复杂的用户界面通常需要很多非常复杂的窗体。为了提高其可复用性、可维护 性和可扩展性,需要创建一个分离用户界面处理的组件,以封装窗体和界面导航之 间的相关逻辑。可以对一个简单窗体中组件之间的依赖、确认和导航应用相冋的概 念 业务层 大型的企业级应用通常围绕业务组件和业务过程进行杓造。这些通常以业务层的很多组件、实体 代理和接凵展现出来。 业务对象:业务对象封装一个业务中的元数据、存储、并发和一件事物的业务规则、过程或 事件。多个独立的但有关联关系的业务对象可以一起协作来完成一个应用。完成不 令用友软件 同的任务需执行很多貝有不同特点的业务对象。业务对象负责执行包括强訇的业务 规则、应用规则、数据有效性、并发和存储等所有方面的内容。业务实体对象是业 务中实际存在的事物或概念,是对“ER”模型中概念的面向对象的扩展。 业务处理对象:描述贯穿业务的工作流程和信息。这些处理驱动业务实体完成业务功能。业 务处理对象叮能由工作流系统、业箦对象管珄器、面向对象语言、程序语言、或交 互过程定义系统实现。通过调度一个或多个业务对象实现业务处理。业务处理可以 作为对象的一部分在内部完成。 服务接口 个应用可能会以服务的方式提供一些功能供其它应用使用。服务接口代表这种对外 的服。它隐臧了实现细节,只提供必要的业务接口。 表小和业务的调用:业务层的调用服务通过平台提供的服务工厂来实现。这样有 利于次开发服务能够动态的护展到应用程序中去 数据层 业竻应用必颁访问存储在数握库中的数据。这些数据库通常是关系数据库。数据访问组件负责访 问存储在这些数据库中的数据,并与业务层进行交互。 数据访问组件隔离业务层和数据存储管理。这种隔离有以下好处 减少数据库提供者变更带来的影响 减少因数据对象变更带来的影响(如变更数据厍的 —封装数据的处理操作,这将在很大程庋上减少测试和维护作: 通过平台提供的数据访问服务组件管理 的复杂度,同时能够再不改变表现层和业务 层的情况下来转换不冋的数据库。 实体数据传递— ntityData 在服务器端和应用服务器端通讯或应用之间通讯时,我们采用粗粒度的服务,使用 来传递数据。在设计时,我们将为每一个实体类自动产生一个 数据类,该类中包 含与实体相同的属性。在前端可以使用数据类,但不能使用实体类。 服务网关 业务组件经常必须访问内部或外部的服务或应用。一个服务网关是封装了接口、协议和使用这种服务 的代码的组件。服务网关可以模拟外部服务促进领域测试。 技术平台(BAP): 基础引擎:服务总线, 系统日志,事务、缓存 认证、安全等内空, 基础组件和模版组件,工作流,数据交换 业务平台(BAP):根据小企业的特点定业业务模式框架 6 用反软件 物理模型 客户端(浏览器) Http Web服务器 应用服务器 21议 UIC LIP Https协议 Service Interfa EAP 数据库服务器 用户界面组件(UIC)和用户界面进程组件(UIP),和业务层接口( Inter face)是对 Internet公开的,并且可能潜在地与许多客户端交互。由于这些表示层组件通常公开于公 司防火墙外部,因此其安全要求通常比未公开的组件具有多得多的限制。此外,许多组织要 求公开于 Interne中的服务器不能包含任何敏感数据。因此,通过将表小层组件单独放入 级并配置该级使其具有最高安全性,可显著提高解决方案的总体安全性,同时可尽量降低 对安全性要求相对较低的组件的影响 山于表示层组件公开于 Internet中,因此其性能和可伸缩性要求通常不同于域和数据 访问层组件的性能和可伸缩性要求。表示层组件通常为处理以突发方式与组件父互的许多并 发用户而进行优化。域和数据访问层组件通常为处理来自相对较少的源所发出的稳定请求流 而进行优化。配置一个可充分支持这两组优化的级可能是非常困难的。因此,解决方案是使 用两级,并使每层针对所驻留的组件类型进行优化 部署路径 扩展纬度+核心应用层 App扩展层 逻辑纬度 Core Extends WEB服务器 FSmart/&Version/Website UFSmart/Version 令用友软件 Website/extend 应用服务器 UFSmart/&Version /App Server UFSmart/Version AppServer/ Entends 数据库服务器 UFSmart/ &Version/ Database UFSmart/& Version Database/Extends 说明:其中& Version版本代表本版要发版的版本标识 4.SDK应用开发 开发环境准备 4.1.1.硬件配置 建议配置信息如下: CPU:双核主频20以上 内存:DR2,2G以上 硬盘:普通SCSⅠ(或SAS)硬盘,磁盘柊式为NTFS容量磁盘剩余空间10G以上 4.1.2.软件配置 建议配置如下: 数据库 操作系统 开发工具 MSSQLServer2005及以| Windows XP、 Window7、 上 Window8、 indow203V2010及以上 Window 2008 4.1.3.SDK包 T+提供相应的开发包 4.1.4.开发规范 开发限制,在后续中逐步完善 用反软件 应用场景开发 格式说明 1、依赖动态库 2、实现接凵 3、配置文件 4、案例 4.2.1.开发表单 基础设置列表及表单开发 4.2.1.1.1.应用场景 在现有T产品中,往往有这种应用场景:对某个业务表以列衣的形式展示处理,并能 对这个业务表进行増、删、改操作。像T+产品中的基础设置下的仓库、业务类型档案的实 现如下: 1、进入档案,展小出档案列表信息界面 首页化导航位库业务类型 新増修改删除栏目扩退出 序号 仓库码 库名称 车也址 鱼查人参与可用且注月 是 是 是 2、新増、修改后进入档案编辑昪面 令用友软件 首页 库业务类型 新怕 退H 仓奉地址负责人库一阿夏话 □厂 上张下张保存保存新没置且的 a lLy://lueallusL: <n00,heUsiLe/DATTLuw/Tss 仓车地 负责 年最 用 loc alhost: 4708 Yebs: te, BAFView/B=3*tt Irtreet 3、保存后退岀,返回到列表,并把新增内容展示在列表咔 首页初始化导就仓库业务类型 新增 册除栏目打印出 序号厂仓库编码仓库名称仓库地址负责人参与可用量停用 否 针对此种场景,我们进行了归纳总结,提供了总体实现方案。 4.2.1.1.2.设计思路 这种场景主要依赖于三个组件:按钮组件、栏目组件和单据组件。通过对场景分析,抽 取岀公共的特性进行分析,规范场景处理流程。对于个性化需求,通过提供扩建接口的方式 来实现。 4.2.1.1.3.应用举例 现在以一个实例讲述这个场景的开发过程 10 【实例截图】
【核心代码】
标签：
好例子网口号：伸出你的我的手 — 分享！
小贴士
感谢您为本站写下的评论，您的评论对其它用户来说具有重要的参考价值，所以请认真填写。
- 类似“顶”、“沙发”之类没有营养的文字，对勤劳贡献的楼主来说是令人沮丧的反馈信息。
- 相信您也不想看到一排文字/表情墙，所以请不要反馈意义不大的重复字符，也请尽量不要纯表情的回复。
- 提问之前请再仔细看一遍楼主的说明，或许是您遗漏了。
- 请勿到处挖坑绊人、招贴广告。既占空间让人厌烦，又没人会搭理，于人于己都无利。
关于好例子网
本站旨在为广大IT学习爱好者提供一个非营利性互相学习交流分享平台。本站所有资源都可以被免费获取学习研究。本站资源来自网友分享，对搜索内容的合法性不具有预见性、识别性、控制性，仅供学习研究，请务必在下载后24小时内给予删除，不得用于其他任何用途，否则后果自负。基于互联网的特殊性，平台无法对用户传输的作品、信息、内容的权属或合法性、安全性、合规性、真实性、科学性、完整权、有效性等进行实质审查；无论平台是否已进行审查，用户均应自行承担因其传输的作品、信息、内容而可能或已经产生的侵权或权属纠纷等法律责任。本站所有资源不代表本站的观点或立场，基于网友分享，根据中国法律《信息网络传播权保护条例》第二十二与二十三条之规定，若资源存在侵权或相关问题请联系本站客服人员，点此联系我们。关于更多版权及免责申明参见 版权及免责申明
网友评论
我要评论