T+产品开发手册作者：T+产品研发部 版本号：1.0 时间：版权所有：畅捷通信息技术有限公司 ChanJet Corp. Ltd.解决党委自身和基层党支部存在的的突出问题，发挥各村、社区、机关单位党支部在当前城市征迁、园区建设、招商引资、服务群众、维护稳定的作用，我镇党委高度重视，制定了切合临淮实际的活动实施方案，按照中央规定的活动步骤和要求扎实有效的开展了基层组织建设年活动。- 57 -1.变更说明目前的 T+平台在不断的完善过程中，因此 T+产品开发过程也会不断变化。下面的表单 用于详细记录本开发手册变更过程。序号变更位置变更内容说明变更人变更日期1234567892.引言2.1. 编写目的随着 T+产品业务的不断扩大，个性化需求越来越多。如何能够让其他人员利用 T+平台 进行个性化开发是要面临的重要问题。同时，随着 T+产品开发人员流动，如何降低新员工 学习成本，更快的融入开发团队，也是亟待解决的问题。为解决以上问题，急需一个成熟的 开发手册。为此，撰写此 T+产品开发手册。2.2. 名词术语说明在开发描述中会涉及到一些通用的名词术语，为便于阅读者理解，对这些名词术语进行 进一步说明。具体说明如下：序号名称术语详细描述变更日期1234567892.3. 参考资料3.开发模型3.1. 拓扑模型IntranetInternet通数据库服务器通应用服务器移动PC通Web服务器 防火墙Web客户端Web客户端Web客户端PDA此系统是一个 B/S 架构的产品，服务器集中部暑。在内部局域网中，用户可以通过浏览 器直接访问 WEB 服务器；其它受管辖的局域网也可以通过专网访问内网中 WEB 服务器；另 外 Internet 用户可以跨越防火墙，通过代理服务器进行业务操作。为了提高性能，我们可以把 web 服务器与应用服务部署在一台服务器上，减少不必要的 远程调用；如果用户想要把 web 服务器与应用服务器进行物理上的分离部暑，我们的应用框 架也支持这种部暑，并且我们采用 http 的传输协议。此系统架构中，采用后台提供服务的架构设计，降低产品中各模块的偶合度。 逻辑模型上面所式三层服务体系结构基本上是一个松散的三层体系结构。三层分别是：表示层。表示层提供应用程序的用户界面 (UI)，处理用户和软件间的交互。主要职责 是向用户显示信息并把从用户获取的信息解释成业务层或者数据源层的各种动作。业务层。业务层实现应用程序的业务逻辑：根据输入或者已有的数据进行计算，对从表 现层输入的数据进行验证，处理从表现层接受到的命令来确定应该调用那些数据源逻辑。数据源层。数据层提供对外部系统（如数据库、和其它系统提供的服务）的访问。 每一层应当按下面各段落所述进行构造表示层： 包括一系列与用户交互的窗体（或页面）。每个窗体用来显示系统提供的信息以及传递 用户的输入信息。这种基于窗体的用户界面包括两种类型的组件：用户界面组件(UI)基于.NET Framework 提供的组件，包括 Win Form 组件和 Web Form 组件。第 三方提供的组件和平台开发的组件。例如：单据、参照、单据列表组件等。用户界面处理组件(UIP) 复杂的用户界面通常需要很多非常复杂的窗体。为了提高其可复用性、可维护性和可扩展性，需要创建一个分离用户界面处理的组件，以封装窗体和界面导航之 间的相关逻辑。可以对一个简单窗体中组件之间的依赖、确认和导航应用相同的概 念。业务层：大型的企业级应用通常围绕业务组件和业务过程进行构造。这些通常以业务层的很多组件、实体、 代理和接口展现出来。业务对象(BE)：业务对象封装一个业务中的元数据、存储、并发和一件事物的业务规则、过程或 事件。多个独立的但有关联关系的业务对象可以一起协作来完成一个应用。完成不同的任务需执行很多具有不同特点的业务对象。业务对象负责执行包括强制的业务 规则、应用规则、数据有效性、并发和存储等所有方面的内容。业务实体对象是业 务中实际存在的事物或概念，是对“ER”模型中概念的面向对象的扩展。业务处理对象(BP)：描述贯穿业务的工作流程和信息。这些处理驱动业务实体完成业务功能。业 务处理对象可能由工作流系统、业务对象管理器、面向对象语言、程序语言、或交 互过程定义系统实现。通过调度一个或多个业务对象实现业务处理。业务处理可以 作为对象的一部分在内部完成。服务接口(Interface)：一个应用可能会以服务的方式提供一些功能供其它应用使用。服务接口代表这种对外 的服务。它隐藏了实现细节，只提供必要的业务接口。表示和业务的调用：业务层的调用服务通过平台提供的服务工厂来实现。这样有 利于二次开发服务能够动态的扩展到应用程序中去。数据层：业务应用必须访问存储在数据库中的数据。这些数据库通常是关系数据库。数据访问组件负责访 问存储在这些数据库中的数据，并与业务层进行交互。数据访问组件隔离业务层和数据存储管理。这种隔离有以下好处：减少数据库提供者变更带来的影响；减少因数据对象变更带来的影响（如变更数据库的schema）；封装数据的处理操作，这将在很大程度上减少测试和维护工作； 通过平台提供的数据访问服务组件管理O-R mapping的复杂度，同时能够再不改变表现层和业务层的情况下来转换不同的数据库。 实体数据传递-EntityData在Web服务器端和应用服务器端通讯或应用之间通讯时，我们采用粗粒度的服务，使用DTO(Data Transfer Object)来传递数据。在设计时，我们将为每一个实体类自动产生一个EntityData数据类，该类中包 含与实体相同的属性。在前端可以使用数据类，但不能使用实体类。服务网关：业务组件经常必须访问内部或外部的服务或应用。一个服务网关是封装了接口、协议和使用这种服务 的代码的组件。服务网关可以模拟外部服务促进领域测试。技术平台（EAP）：基础引擎：服务总线，O-R Maping,系统日志，事务、缓存、Ajax，认证、安全 等内容， 基础组件和模版组件，工作流，数据交换业务平台（BAP）：根据小企业的特点定业业务模式框架3.2. 物理模型客户端（浏览器）0.*Http1.1Web服务器应用服务器T21协议UICUIPHttps协议1.1ServiceBPInterfaceEAPBEEAP1.1数据库服务器用户界面组件 (UIC) 和用户界面进程组件 (UIP)，和业务层接口（Interface） 是对 Internet 公开的，并且可能潜在地与许多客户端交互。由于这些表示层组件通常公开于公 司防火墙外部，因此其安全要求通常比未公开的组件具有多得多的限制。此外，许多组织要 求公开于 Internet 中的服务器不能包含任何敏感数据。因此，通过将表示层组件单独放入 一级并配置该级使其具有最高安全性，可显著提高解决方案的总体安全性，同时可尽量降低 对安全性要求相对较低的组件的影响。由于表示层组件公开于 Internet 中，因此其性能和可伸缩性要求通常不同于域和数据 访问层组件的性能和可伸缩性要求。表示层组件通常为处理以突发方式与组件交互的许多并 发用户而进行优化。域和数据访问层组件通常为处理来自相对较少的源所发出的稳定请求流 而进行优化。配置一个可充分支持这两组优化的级可能是非常困难的。因此，解决方案是使 用两级，并使每一层针对所驻留的组件类型进行优化3.3. 部署路径扩展纬度逻辑纬度T+核心应用层App 扩展层CoreExtendsWEB 服务器UFSmart/&Version/WebsiteUFSmart/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.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+产品中的基础设置下的仓库、业务类型档案的实 现如下：1、进入档案，展示出档案列表信息界面2、新增、修改后进入档案编辑界面3、保存后退出，返回到列表，并把新增内容展示在列表中针对此种场景，我们进行了归纳总结，提供了总体实现方案。4.2.1.1.2.设计思路这种场景主要依赖于三个组件：按钮组件、栏目组件和单据组件。通过对场景分析，抽 取出公共的特性进行分析，规范场景处理流程。对于个性化需求，通过提供扩建接口的方式 来实现。4.2.1.1.3.应用举例现在以一个实例讲述这个场景的开发过程。需求如下：XX 公司想在 T+系统中增加一个基础档案：物流公司档案。4.2.1.1.3.1. 第一步：确定菜单名称及编码，并创建菜单要创建 XX 公司二次开发菜单，开发主菜单我们暂命名为:xx 公司管理(这个名称由二次 开发公司自己命名或根据客户需求命名)，菜单编码命名为：AppCjtIDXX，其中 App 是 T+规 定，必须以此前缀命名，CjtID 是由畅捷通分配给二次开发公司的唯一 ID，XX 可以由二次 开发公司自己任意确定。对于物流公司档案这个子菜单，Code 可以命名为 App