t产品开发手册.docx
《t产品开发手册.docx》由会员分享,可在线阅读,更多相关《t产品开发手册.docx(209页珍藏版)》请在三一文库上搜索。
1、T+产品开发手册作者:T+产品研发部 版本号:1.0 时间:版权所有:畅捷通信息技术有限公司 ChanJet Corp. Ltd.- 58 -1.变更说明目前的 T+平台在不断的完善过程中,因此 T+产品开发过程也会不断变化。下面的表单 用于详细记录本开发手册变更过程。序号变更位置变更内容说明变更人变更日期1234567892.引言2.1. 编写目的随着 T+产品业务的不断扩大,个性化需求越来越多。如何能够让其他人员利用 T+平台 进行个性化开发是要面临的重要问题。同时,随着 T+产品开发人员流动,如何降低新员工 学习成本,更快的融入开发团队,也是亟待解决的问题。为解决以上问题,急需一个成熟的
2、 开发手册。为此,撰写此 T+产品开发手册。2.2. 名词术语说明在开发描述中会涉及到一些通用的名词术语,为便于阅读者理解,对这些名词术语进行 进一步说明。具体说明如下:序号名称术语详细描述变更日期1234567892.3. 参考资料3.开发模型3.1. 拓扑模型IntranetInternet通数据库服务器通应用服务器移动PC通Web服务器 防火墙Web客户端Web客户端Web客户端PDA此系统是一个 B/S 架构的产品,服务器集中部暑。在内部局域网中,用户可以通过浏览 器直接访问 WEB 服务器;其它受管辖的局域网也可以通过专网访问内网中 WEB 服务器;另 外 Internet 用户可以
3、跨越防火墙,通过代理服务器进行业务操作。为了提高性能,我们可以把 web 服务器与应用服务部署在一台服务器上,减少不必要的 远程调用;如果用户想要把 web 服务器与应用服务器进行物理上的分离部暑,我们的应用框 架也支持这种部暑,并且我们采用 http 的传输协议。此系统架构中,采用后台提供服务的架构设计,降低产品中各模块的偶合度。 逻辑模型上面所式三层服务体系结构基本上是一个松散的三层体系结构。三层分别是:表示层。表示层提供应用程序的用户界面 (UI),处理用户和软件间的交互。主要职责 是向用户显示信息并把从用户获取的信息解释成业务层或者数据源层的各种动作。业务层。业务层实现应用程序的业务逻
4、辑:根据输入或者已有的数据进行计算,对从表 现层输入的数据进行验证,处理从表现层接受到的命令来确定应该调用那些数据源逻辑。数据源层。数据层提供对外部系统(如数据库、和其它系统提供的服务)的访问。 每一层应当按下面各段落所述进行构造表示层: 包括一系列与用户交互的窗体(或页面)。每个窗体用来显示系统提供的信息以及传递 用户的输入信息。这种基于窗体的用户界面包括两种类型的组件:用户界面组件(UI)基于.NET Framework 提供的组件,包括 Win Form 组件和 Web Form 组件。第 三方提供的组件和平台开发的组件。例如:单据、参照、单据列表组件等。用户界面处理组件(UIP) 复杂
5、的用户界面通常需要很多非常复杂的窗体。为了提高其可复用性、可维护性和可扩展性,需要创建一个分离用户界面处理的组件,以封装窗体和界面导航之 间的相关逻辑。可以对一个简单窗体中组件之间的依赖、确认和导航应用相同的概 念。业务层:大型的企业级应用通常围绕业务组件和业务过程进行构造。这些通常以业务层的很多组件、实体、 代理和接口展现出来。业务对象(BE):业务对象封装一个业务中的元数据、存储、并发和一件事物的业务规则、过程或 事件。多个独立的但有关联关系的业务对象可以一起协作来完成一个应用。完成不同的任务需执行很多具有不同特点的业务对象。业务对象负责执行包括强制的业务 规则、应用规则、数据有效性、并发
6、和存储等所有方面的内容。业务实体对象是业 务中实际存在的事物或概念,是对“ER”模型中概念的面向对象的扩展。业务处理对象(BP):描述贯穿业务的工作流程和信息。这些处理驱动业务实体完成业务功能。业 务处理对象可能由工作流系统、业务对象管理器、面向对象语言、程序语言、或交 互过程定义系统实现。通过调度一个或多个业务对象实现业务处理。业务处理可以 作为对象的一部分在内部完成。服务接口(Interface):一个应用可能会以服务的方式提供一些功能供其它应用使用。服务接口代表这种对外 的服务。它隐藏了实现细节,只提供必要的业务接口。表示和业务的调用:业务层的调用服务通过平台提供的服务工厂来实现。这样有
7、 利于二次开发服务能够动态的扩展到应用程序中去。数据层:业务应用必须访问存储在数据库中的数据。这些数据库通常是关系数据库。数据访问组件负责访 问存储在这些数据库中的数据,并与业务层进行交互。数据访问组件隔离业务层和数据存储管理。这种隔离有以下好处:减少数据库提供者变更带来的影响;减少因数据对象变更带来的影响(如变更数据库的schema);封装数据的处理操作,这将在很大程度上减少测试和维护工作; 通过平台提供的数据访问服务组件管理O-R mapping的复杂度,同时能够再不改变表现层和业务层的情况下来转换不同的数据库。 实体数据传递-EntityData在Web服务器端和应用服务器端通讯或应用之
8、间通讯时,我们采用粗粒度的服务,使用DTO(Data Transfer Object)来传递数据。在设计时,我们将为每一个实体类自动产生一个EntityData数据类,该类中包 含与实体相同的属性。在前端可以使用数据类,但不能使用实体类。服务网关:业务组件经常必须访问内部或外部的服务或应用。一个服务网关是封装了接口、协议和使用这种服务 的代码的组件。服务网关可以模拟外部服务促进领域测试。技术平台(EAP):基础引擎:服务总线,O-R Maping,系统日志,事务、缓存、Ajax,认证、安全 等内容, 基础组件和模版组件,工作流,数据交换业务平台(BAP):根据小企业的特点定业业务模式框架3.2
9、 物理模型客户端(浏览器)0.*Http1.1Web服务器应用服务器T21协议UICUIPHttps协议1.1ServiceBPInterfaceEAPBEEAP1.1数据库服务器用户界面组件 (UIC) 和用户界面进程组件 (UIP),和业务层接口(Interface) 是对 Internet 公开的,并且可能潜在地与许多客户端交互。由于这些表示层组件通常公开于公 司防火墙外部,因此其安全要求通常比未公开的组件具有多得多的限制。此外,许多组织要 求公开于 Internet 中的服务器不能包含任何敏感数据。因此,通过将表示层组件单独放入 一级并配置该级使其具有最高安全性,可显著提高解决方案的
10、总体安全性,同时可尽量降低 对安全性要求相对较低的组件的影响。由于表示层组件公开于 Internet 中,因此其性能和可伸缩性要求通常不同于域和数据 访问层组件的性能和可伸缩性要求。表示层组件通常为处理以突发方式与组件交互的许多并 发用户而进行优化。域和数据访问层组件通常为处理来自相对较少的源所发出的稳定请求流 而进行优化。配置一个可充分支持这两组优化的级可能是非常困难的。因此,解决方案是使 用两级,并使每一层针对所驻留的组件类型进行优化3.3. 部署路径扩展纬度逻辑纬度T+核心应用层App 扩展层CoreExtendsWEB 服务器UFSmart/&Version/WebsiteUFSmar
11、t/Version/Website/Extends应用服务器UFSmart/&Version /AppServerUFSmart/Version/AppServer /Entends数据库服务器UFSmart/&Version /DatabaseUFSmart/&Version/Database/Extends说明:其中&Version 版本代表本版要发版的版本标识4.SDK 应用开发4.1. 开发环境准备4.1.1.硬件配置建议配置信息如下:CPU :双核主频 2G 以上 内存:DDR2,2G 以上硬盘:普通 SCSI(或 SAS)硬盘,磁盘格式为 NTFS 容量磁盘剩余空间 40G 以上4
12、1.2.软件配置建议配置如下:数据库操作系统开发工具MSSQLServer2005 及以 上Windows XP、Window7、 Window8、Window2003、 Window2008Vs2010 及以上4.1.3. SDK 包T+提供相应的开发包4.1.4.开发规范开发限制,在后续中逐步完善4.2. 应用场景开发格式说明:1、 依赖动态库2、 实现接口3、 配置文件4、 案例4.2.1.开发表单4.2.1.1.基础设置列表及表单开发4.2.1.1.1.应用场景在现有 T+产品中,往往有这种应用场景:对某个业务表以列表的形式展示处理,并能 对这个业务表进行增、删、改操作。像 T+产品
13、中的基础设置下的仓库、业务类型档案的实 现如下:1、进入档案,展示出档案列表信息界面2、新增、修改后进入档案编辑界面3、保存后退出,返回到列表,并把新增内容展示在列表中针对此种场景,我们进行了归纳总结,提供了总体实现方案。4.2.1.1.2.设计思路这种场景主要依赖于三个组件:按钮组件、栏目组件和单据组件。通过对场景分析,抽 取出公共的特性进行分析,规范场景处理流程。对于个性化需求,通过提供扩建接口的方式 来实现。4.2.1.1.3.应用举例现在以一个实例讲述这个场景的开发过程。需求如下:XX 公司想在 T+系统中增加一个基础档案:物流公司档案。4.2.1.1.3.1. 第一步:确定菜单名称及
14、编码,并创建菜单要创建 XX 公司二次开发菜单,开发主菜单我们暂命名为:xx 公司管理(这个名称由二次 开发公司自己命名或根据客户需求命名),菜单编码命名为:AppCjtIDXX,其中 App 是 T+规 定,必须以此前缀命名,CjtID 是由畅捷通分配给二次开发公司的唯一 ID,XX 可以由二次 开发公司自己任意确定。对于物流公司档案这个子菜单,Code 可以命名为 AppCjtIDAA01.目 前 菜 单 创 建 已 提 供 可 视 化 工 具 , 工 具 目 录 为 开 发 包 下 的 AppServerserverPrivilegeTool.exe,菜单创建过程如下:1、 进入工具,输
15、入数据库连接信息及 T+产品账套,进入菜单预置主界面2、 进入菜单预置界面,创建“xx 公司管理”主菜单注意:红色标注的是要重点输入的地方3、 在“xx 公司管理”主菜单下创建“物流公司”子菜单至此,菜单创建工作完成。4.2.1.1.3.2. 第二步:创建 DTO 项目文件1、 创 建Ufida.T.App.CjtID.DTO项 目 文 件 , 并 引 用Ufida.T.AA.DTO.dll, Ufida.T.EAP.DataStruct.dll 两个 T+开发包自动的 dll,其中 Ufida.T.AA.DTO.dll属于 T+基础档案类库,如果在二次开发 DTO 中用到 T+基础档案类库,
16、可以引用此 dll, 如果没有引用到 T+基础档案类库,可以不引用。创建过程如下图所示:2、 修改 DTO 工程文件属性信息依据 T+产品框架结构,DTO 应该至于 Appseverserver 和 Websitebin 下,因此在创建 工程文件时,最好提前设置。本实例首先把 Ufida.T.App.CjtID.DTO.dll 生成到一个公 共文件 pubref 下,然后在生成后事件里,从 pubref 下 copy 到开发包 Appserverserver 和 Websitebin 两个目录下。如下图设置所示:4.2.1.1.3.3. 第三步:创建物流公司档案 DTO目 前 已 提 供 DT
17、O 可 视 化 工 具 , 工 具 地 址 开 发 包 下 Appserverserver Ufida.T.EAP.Tool.StartDesigner.exe1、 对 DTO 包进行命名依据规则对“XX 公司管理”命名,包标题为:xx 公司管理 DTO(可根据开发者习惯 命名),名称为 Ufida_T_App_CjtID_DTO(Ufida_T_App_CjtID 部分是 T+要求,后面 可以开发者自己确定),命名空间为 Ufida.T.App.CjtID.DTO(与第二步中 DTO 项目 保持一致),vs 项目则选择第二步所创建的项目文件路径。如下图所示:2、 包保存成功后进入包,创建物流
18、公司档案 DTOa)创建物流公司 DTO 基本属性目前已提供了 DTO 的基本属性,只需在创建界面上打勾选择即可,其中 DTO 名称根据开发者自己命名,为避免在引用中和 T+类库冲突,也便于通过 DTO 名称 直接区分,DTO 名称前建议加上 CjtID;数据库表名规定前面部分为 AppCjtID_; 而 Ts、upadateBy、updated、名称字段、编号字段必须打勾,如下图所示:b)添加物流公司 DTO 档案属性除了 DTO 公共属性,每个档案都有自己的属性。这可以根据需求,通过 DTO 设计器进行创建,如下图所示:其中物流公司名称、物流公司编码是文本类型的,而所属仓库是引用的 T+基
19、 础档案。c)通过 DTO 设计器生成物流公司 DTO 代码选中 DTO,通过操作:“生成代码”-“选中 DTO”,则生成的 DTO 代码保存到 项目工程文件下。此操作只生成一个 DTO 代码,如果 DTO 比较多,可通过操作“生 成代码”-“按包生成”,全部生成最好不要操作,这个是生成的 DTO 设计器下的 所有 DTO,包括 T+产品原有的。操作过程如下所示:d)查看生成的 DTO 代码并编译通过生成后,我们会发现 DTO 项目文件中多了我们设计的 DTO 代码,编译此工 程文件,没有错误,则此档案 DTO 设计完成。如下图所示:e)导出 DTO 元数据脚本和数据库结构脚本通过 DTO 设
20、计器中“元数据”菜单下的“导出 DTO 元数据”和“生成业务表脚 本功能”,导出 DTO 元数据脚本和数据库结构脚本,以供做包使用。至此,DTO 创建工作全部完成。4.2.1.1.3.4. 第四步:创建程序代码依据 T+产品架构,创建新增业务前后台代码。 1、 创建 BE 层实体类BE 层主要用于处理实体类简单的业务逻辑,放在安装包 Appserverserver 层。创建流 程如下:其中 BE 项目文件需要引用 T+类库中的 Ufida.T.BAP.BusinessApplication.dll、 Ufida.T.EAP.DataStruct.dll 和自己开发 的 Ufida.T.App.
21、CjtID.DTO.dll , 实体 类 CjtIDLogisticBE 需要继承基类 BusinessEntityTemplate,其他的暂时 不管。编译BE生成dll2、 创建 BP 层实体类BP 层主要处理实体类的主要业务逻辑,放在安装包 Appserverserver 层。创建流 程如下:其中BP项目文件需要引用T+类库中的Ufida.T.Bap.Base.dll、 Ufida.T.Bap.BusinessApplication.dll、Ufida.T.EAP.DataStruct.dll三个类库以及自己 开发的Ufida.T.App.CjtID.DTO.dll、Ufida.T.App
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 产品 开发 手册
