作者：T+产品研发部 版本号： Framework 提供的组件，包括 Win Form 组件和 Web Form 组件。第 三 方提供的组件和平台开发的组件。例如：单据、参照、单据列表组件等。 ――用户界面处理组件(UIP) 复杂的用户界面通常需要很多非常复杂的窗体。 为 了提高其可复用性、 可维护 性和可扩展性， 需要创建一个分离用户界面处理的组件， 以封装窗体和界面导航之 间的相关逻辑。
可以对一个简单窗体中组件之间的依赖、 确认和导航应用相同的概 念。 业务层：
大型的企业级应用通常围绕业务组件和业务过程进行构造。这些通常以业务层的很多组件、实体、 代理 和接口展现出来。 业务对象(BE)：业务对象封装一个业务中的元数据、存储、并发和一件事物的业务规则、过程或 事件。多个独立的但有关联关系的业务对象可以一起协作来完成一个应用。完成不
同的任务需执行很多具有不同特点的业务对象。业务对象负责执行包括强制的业务 规则、应用规则、数据有效性、并发和存储等所有方面的内容。业务实体对象是业 务中实际存在的事物或概念，是对“ER”模型中概念的面向对象的扩展。 业务处理对象(BP)：描述贯穿业务的工作流程和信息。这些处理驱动业务实体完成业务功能。业 务处理对象可能由工作流系统、业务对象管理器、面向对象语言、程序语言、或交
互过程定义系统实现。通过调度一个或多个业务对象实现业务处理。业务处理可以 作为对象的一部分在内部完成。 服务接口(Interface)： 一个应用可能会以服务的方式提供一些功能供其它应用使用。服务接口代表这种对外 的服务。它隐藏了实现细节，只提供必要的业务接口。
表示和业务的调用：业务层的调用服务通过平台提供的服务工厂来实现。这样有 利于二次开发服务能够动态的扩展到应用程序中去。 ? 数据层：
业务应用必须访问存储在数据库中的数据。这些数据库通常是关系数据库。数据访问组件负责访 问存储在这些数据库中的数据，并与业务层进行交互。 数据访问组件隔离业务层和数据存储管理。这种隔离有以下好处： ――减少数据库提供者变更带来的影响； ――减少因数据对象变更带来的影响（如变更数据库的 schema）； ――封装数据的处理操作，这将在很大程度上减少测试和维护工作； 通过平台提供的数据访问
服务组件管理 O-R mapping 的复杂度，同时能够再不改变表现层和业务 层的情况下来转换不同的数据库。
在 Web 服务器端和应用服务器端通讯或应用之间通讯时，我们采用粗粒度的服务，使用 DTO(Data
Transfer Object)来传递数据。在设计时，我们将为每一个实体类自动产生一个 EntityData 数据类，该类中包 含与实体相同的属性。在前端可以使用数据类，但不能使用实体类。 服务网关： 业务组件经常必须访问内部或外部的服务或应用。一个服务网关是封装了接口、协议和使用这种服务 的代码的组件。服务网关可以模拟外部服务促进领域测试。
技术平台（EAP） ：
基础引擎：服务总线，O-R Maping,系统日志，事务、缓存、Ajax，认证、安全 等内容， 基础组件 和模版组件，工作流，数据交换
业务平台（BAP） ：根据小企业的特点定业业务模式框架
用户界面组件 (UIC) 和用户界面进程组件 (UIP)，和业务层接口（Interface） 是对 Internet 公开的，并且可能潜在地与许多客户端交互。由于这些表示层组件通常公开于公 司防火墙外部，因此其安全要求通常比未公开的组件具有多得多的限制。此外，许多组织要 求公开于 Internet 中的服务器不能包含任何敏感数据。因此，通过将表示层组件单独放入
一级并配置该级使其具有最高安全性， 可显著提高解决方案的总体安全性， 同时可尽量降低 对安全性要求相对较低的组件的影响。 由于表示层组件公开于 Internet 中， 因此其性能和可伸缩性要求通常不同于域和数据 访问层组件的性能和可伸缩性要求。 表示层组件通常为处理以突发方式与组件交互的许多并 发用户而进行优化。 域和数据访问层组件通常为处理来自相对较少的源所发出的稳定请求流
而进行优化。配置一个可充分支持这两组优化的级可能是非常困难的。因此，解决方案是使 用两级，并使每一层针对所驻留的组件类型进行优化
应用服务器 数据库服务器
说明:其中&Version 版本代表本版要发版的版本标识
建议配置信息如下： CPU ：双核主频 2G 以上 内存： DDR2,2G 以上 硬盘：普通 SCSI（或 SAS）硬盘，磁盘格式为 NTFS 容量磁盘剩余空间 40G 以上
数据库 操作系统 开发工具
开发限制，在后续中逐步完善
4.2. 应用场景开发
格式说明： 1、 依赖动态库 2、 实现接口 3、 配置文件 4、 案例
基础设置列表及表单开发
在现有 T+产品中，往往有这种应用场景：对某个业务表以列表的形式展示处理，并能 对这个业务表进行增、删、改操作。像 T+产品中的基础设置下的仓库、业务类型档案的实 现如下： 1、进入档案，展示出档案列表信息界面
2、新增、修改后进入档案编辑界面
3、保存后退出，返回到列表，并把新增内容展示在列表中
针对此种场景，我们进行了归纳总结，提供了总体实现方案。
这种场景主要依赖于三个组件：按钮组件、栏目组件和单据组件。通过对场景分析，抽 取出公共的特性进行分析，规范场景处理流程。对于个性化需求，通过提供扩建接口的方式 来实现。
现在以一个实例讲述这个场景的开发过程。
需求如下：XX 公司想在 T+系统中增加一个基础档案：物流公司档案。
4.2.1.1.3.1. 第一步：确定菜单名称及编码，并创建菜单
要创建 XX 公司二次开发菜单， 开发主菜单我们暂命名为:xx 公司管理(这个名称由二次 开发公司自己命名或根据客户需求命名)，菜单编码命名为：AppCjtIDXX，其中 App 是 T+规 定，必须以此前缀命名，CjtID 是由畅捷通分配给二次开发公司的唯一 ID，XX 可以由二次 开发公司自己任意确定。对于物流公司档案这个子菜单，Code 可以命名为 AppCjtIDAA01. 目 前 菜
2、 进入菜单预置界面，创建“xx 公司管理”主菜单
注意：红色标注的是要重点输入的地方 3、 在“xx 公司管理”主菜单下创建“物流公司”子菜单
至此，菜单创建工作完成。
属于 T+基础档案类库， 如果在二次开发 DTO 中用到 T+基础档案类库， 可以引用此 dll， 如 果没有引用到 T+基础档案类库，可以不引用。创建过程如下图所示：
和 Website\bin 两个目录下。如下图设置所示：
2、 包保存成功后进入包，创建物流公司档案 DTO
a) 创建物流公司 DTO 基本属性 目前已提供了 DTO 的基本属性，只需在创建界面上打勾选择即可，其中 DTO 名称根据开发者自己命名，为避免在引用中和 T+类库冲突，也便于通过 DTO 名称 直接区分，DTO 名称前建议加上 CjtID；数据库表名规定前面部分为 AppCjtID_； 而 Ts、upadateBy、updated、名称字段、编号字段必须打勾，如下图所示：
b) 添加物流公司 DTO 档案属性 除了 DTO 公共属性，每个档案都有自己的属性。这可以根据需求，通过 DTO 设计器进行创建，如下图所示：
其中物流公司名称、物流公司编码是文本类型的，而所属仓库是引用的 T+基 础档案。 c) 通过 DTO 设计器生成物流公司 DTO 代码 选中 DTO，通过操作： “生成代码”->“选中 DTO” ，则生成的 DTO 代码保存到 项目工程文件下。此操作只生成一个 DTO 代码，如果 DTO 比较多，可通过操作“生 成代码”->“按包生成” ，全部生成最好不要操作，这个是生成的
DTO 设计器下的 所有 DTO，包括 T+产品原有的。操作过程如下所示：
d) 查看生成的 DTO 代码并编译
通过生成后， 我们会发现 DTO 项目文件中多了我们设计的 DTO 代码， 编译此工 程文件， 没有错误，则此档案 DTO 设计完成。如下图所示：
e) 导出 DTO 元数据脚本和数据库结构脚本 通过 DTO 设计器中“元数据”菜单下的“导出 DTO 元数据”和“生成业务表脚 本功能” ， 导出 DTO 元数据脚本和数据库结构脚本，以供做包使用。 至此，DTO 创建工作全部完成。
依据 T+产品架构，创建新增业务前后台代码。 1、 创建 BE 层实体类 BE 层主要用于处理实体类简单的业务逻辑，放在安装包 Appserver\server 层。创建流 程如下：
2、 创建 BP 层实体类 BP 层主要处理实体类的主要业务逻辑，放在安装包 Appserver\server 层。创建流 程如下：
4、 创建 Service 层实体类 Service 层主要用于接口的具体实现，可自己独立完成相应的业务逻辑处理，也可调用 BE、BP 辅助完成相应的业务逻辑处理。放在安装包 Appserver\server 下。创建流程如 下：
UIP 层主要用于处理前台逻辑。并通过接口调用方式完成前台与后台交互。放在安装包
编译生成 dll。 至此，代码框架结构创建完成。总体来说，代码结构如下：
在列表展示时， 该列表所展示的列是通过栏目预置的方式实现。 栏目预置目前已提供相 应的可视化工具，目前的位置在开发包 Appserver\server\ T.EAP.IDE.exe(注：目前提供 的包里暂时不包括此工具，有待完善)。针对物流公司我需要展示“物流公司名称” 、 “物流 公司编码” 、 “所属仓库”等字段，则栏目预置过程如下： 1、 确定栏目方案名称
此栏目方案名称开发者可任意名称， 为避免重复， 建议前面加上 AppCjtID_,此栏目 预置为：AppCjtID_LogisticColumn。 2、 进入栏目预置工具（暂时这样使用，以后会加以改进） 进入如下界面：
点击栏目，进入栏目预置界面：
3、 预置必输字段 在栏目实现时，主要依赖于每个 DTO 的 ID 和 Ts 列，所以这两列必须预置，且是系 统 字段和用于开发字段。如图所示： a) 新增方案
b) 为方案新增必输字段
其中这两个字段小数位数、精度必须为 null，是系统字段，且是必选字段。另外 ID、 Ts 名字也按照上述预置，区分大小写。 如果以上预置不符合条件，请通过如下语句修 改：
其中需要注意的：字符类型的小数位数和精度字段必须为 null，字段预置和 DTO 对应，如 果是引用关系，则依据 DTO 中属性层级关系预置，如上图所属仓库预置。 5、 导出脚本 通过工具中“导出”菜单，则导出栏 目预置脚本 至此，栏目预置完成。
2、 确定物流公司卡片表单名称并创建 表单命名开发者可以自己定义，对于物流公司卡片表单，命名为： AppCjtIDLogisticVoucher
其中表单创建必须依赖于已存在 DTO。 3、 通过拖拽方式创建表单
如上图所示，对于文本类型的属性，直接拖拽，一般不用进行修改即可。对于引用类型的则 需要设置对一些属性进行设置，以满足控件要求，比如下拉参照等。 4、 导出元数据脚本 通过工具的“导出元数据”功能，实现对表单原始的导出，如下图所 示：
至此卡片表单预置完成。
通过以上 6 步数据及代码准备工作，基础设置列表及表单开发可以如下配置并实现： 1、 Website 创建独立的运行目录，命名为 AppCjtID
如红色标注所示：需要声明 ClientObject 属性，参数为前台 js 类名，并注册脚本。 5、 新建卡片列表前台处理脚步，并修改对应的后台处理类。 a) 在 Website/AppCjtID/Js 下新增脚本文件 CjtIDLogisticList.js 并添加内容如下：
如红色标注所示：需要声明 ClientObject 属性，参数为前台 js 类名，并注册脚本。 c)重新编译此 dll 6、 修改服务配置文件 服务配置文件，在安装包 Appserver\config 目录下涉及到配置文件的修改如下： 可以在原有配置文件的基础上新增服务接口配置，也可以重新创建自己的服务接口 配置文件，并把此配置文件添加上服务配置中，目前采用后者配置如下： a)修改
经过以上 7 个步骤后，现在我们进入产品，就可以看到我们新增这个功能的效果了。
单据表单在 T+产品中非常常见，像采购订单、销售订单等，如下图所示：
基于这类产品的共性，T+平台进行了抽取，实现了基本的功能。
通过业务需求分析,确定数据传输对象实体（DTO） ，关于 DTO 设计可以通过平台提供的 DTO 设计器来完成。
DTO 设计完成后，生成对应的表结构和源代码，这个都可以通过工具进行导出生成。
联查：是一个超链接，有时候在一个报表中某条记录是对明细项的汇总，我们需要通过联查 来知道这条记录所对应的明细项。 分级汇总：以地区为例，现有： “华北区―北京市―海淀区” ，如果按地区 1 级汇总，则把属 于华北区的北京市的数据汇总到“华北区” ，共显示一行；如果按地区 2 级汇总， 则把属于华北区的北京市的数据汇总到“华北区” ，再把属于北京市的海淀区的 数据汇总到“北京市”
，共显示两行。 分组汇总：按指定的条件对明细项分组，最终显示的是每一组的汇总值，明细项不显示 分 组小计：按指定的条件对明细项分组，每一组中明细项都显示出来，最后再对这一组的明 细进行汇总。 表头带入项： 把查询条件带入到报表最终所展现的页面中来， 带入的查询条件显示在报表的 头部。
报表主要是有下面几部分组成的： （1）预置数据：包括字段预置、栏目预置、查询预置、分组预置、字段权限预置等。 （2）报表服务 Server：获得动态 sql。 （3）UIP：主要负责处理表头带入项，自定义的控制、显示。 （4）联查处理：有模块内的联查和跨模块联查。 （5）后置选项控制：根据设置，控制查询、分组、栏目中字段的可见性。 （6）配置文件：配置
Server、UIP、账套选项前置校验和后置操作类配置。 下面的章 节将详细介绍这几点
1 分析和设计数据源 SQL
确定了字段和数据来源后，要通过把以上信息元数据化，元数据化最有效的办法是使 用工具，后面是有关工具使用的说明。
用最新的安装包建立账套，进入安装包的 Appserver\server 目录下，运行 DBConfig， 配置数据库。
关于 Appserver\server 目录下的 ReportBuilder.exe， 提供对报表的列显示、 列排序、 分组、小计、合计、是否排序条件、排序方式以及客户可见进行设置，初始化客户在报表的 设置期间是否可以看见某一列的设置以及显示， 字段成组， 分级， 自定义项， 自由项的预置。
打开报表预置工具，右击，选择 ‖新建报表‖，在弹出的输入框里填入相应的‖报表名
称‖、‖报表标题‖，选择对应的‖报表类型‖，在‖主 SQL‖的输入框里粘贴 1 步骤形成的数据源 SQL，最后，‖菜单功能编码‖填入 EAP_Menu 对应的编码。 有关‖报表名称‖的命名参见命名规范文档。 注意：‖菜单功能编码‖文本框不可为空或 误填，否则报表的权限控制会失效。
选择新建的报表标题，进入‖字段设置‖， 点击【从 SQL 导入】 ，就会解析 SQL，生成字
段（也可以点击【增加字段】 ） ，这样设计数据源 SQL 字段就都导入到 eap_reportfield 这张 表了， 但其 title 字段还是 SQL 名称， 且没有成组的信息， 需要参照相应的需求文档做修改。 【字段名称】SQL 中 AS 后面部分，也就是字段的别名。 【字段标题】按照需求文档的【查询结果】的【字段】名称预置。 【选择字段】SQL 中 AS
前面部分，如果命名规范，直接加点就行。 【查询名称】将来拼写 where 条件的，由于这个字段会用到 eap_reporttablecol 中 selectfieldname，需要拼成类似与【selectfieldname】+”as”+【别名】 。如果三个预置 数据都是一样，不符合 sql 语法规则，会报错。
当报表工具左边的成组字段都改成需求文档的名称后，还需要手动点击“增加成组”按 钮，将逻辑成组的字段放在对应的组里。 根据需求文档的【分组】设置可分组，也就是【列名】显示的名称都要勾选“可分组” 。
理解需求各字段的含义，自己总结增加逻辑上面的【成组】 ，每个成组有且只能有一个 【主字段】 。 【小提示】 ：展现给用户的时候，成组内的字段位置只能在本组内移动，也可以整组移 动，联查传递数据是一个整体。 明细表一般是一个引用型的对象包含一个组， 特别要添加一个 ID， 如 【币种】 ， 将来 【分 组汇总】 【汇总小计】 【联查】的时候主要依据就是此成组中的【主字段】
统计表，另外还要根据需求的【分组】显示内容【成组】 ，如例子中的【单据编号】 注意：分组字段的“主字段“的一定要选 ID 或编码字段。
按照需求的【查询结果】顺序调整字段的排序，点击【上移】 【下移】按钮，注意是操 作
左边栏目数据的移动。 【增加列头】点击后，弹出窗体，输入【名称】和【标题】 ，点击【确定】 ，左边会增加 列 头，注意和逻辑上的【成组】区分，仔细看图标不一致。
多列头实际运行时的效果，如下所示：
根据需求的【查询结果】表设置显示情况： 【可显示】对应于需求的【字段】列， 【显示】对应于需求的【默认显示】列。 对于数值型 还需要设置【可合计】 【合计】 ， 【可合计】根据需求设置成【1―sum】 。 注意：一些报表的 “单价”或“报价”字段，还有些字段的需求规定“不进行小计与合计” 的都不需要设置 【可合计】 【合计】项。 统计表（或执行表）既不在分组，也不是合计的某些列，但是还要
【排序类型】按照需求设置【升序】 【降序】 【无】 【格式】如金额设为 N，日期：D，加%为 P，具体参见帮助（红框的按钮）
【样式】设置样式，具体看帮助
；如数值型，如果为负数，则显示红色：
注：带线条显示的需要修改成栏目设置的字段名称。
【链接】 命名规范参 见规范文档 举例如下： 【进货单统计表】联查到【进货单明细表】
【链接标题】如：进货单明细表；查看进货单 【链接提示】如：查看进货单明细表；查看进货单 【参考人机规范规定如下】1、如果是报表联查报表，则在报表工具的“栏目设置”中将“链 接标题”列输入被联查报表的菜单名， “链接提示”列输入“查看＋菜单名”; 2、如果是报表联查单据，则在报表工具的“栏目设置”中将“链接标题”列输入“查 看＋被联查单据菜单名” ， “链接提示”列输入“查看＋菜单名”
预置分组： 【序号】参见需求的【分组】顺序 【分组名称】参见需求的【分组】中的【列名】 【分组小计】参见参见需求的【分组】中的【默认分组小计】 【分组汇总】参见参见需求的【分组】中的【默认分组汇总】
【简单查询】来自于需求的【过滤条件】的【列名】
注意：设置完毕之后，需要使用 searchTool 进一步设置，不要使用右下角的设置！ 至少保存一次,否则看到的东西不会保存到数据库，报错：找不到查询方案
查询预置工具提供了设置报表高级或简单查询的过滤条件字段，查询页面中显示查询 条件的预置。 注意：首先参照需求文档的【过滤条件】设置【简单方案】 ；
【过滤条件】表格的【类型】对应查询工具的“控件类型” ，设置如下： 逻辑类型： “控件 类型”设为 CheckBox，默认值也需要设置为要求的数值。 日期类型： “控件类型”设为 DateSelectDropDown，条件值类型设为 Text 类型，默认值根 据需求说明设置。 枚举类型： “控件类型”设为 ComboBox，默认值根据需求设置。 数值类型： “控件类型”设 为
NumTextBox，条件值类型设为 Text 类型。 字符类型：需要根据【过滤条件】表格的 【说明】内容设置“控件类型” 。 【说明】包含‖区间查询‖与‖参照‖,“控件类型”设为 RefComboBox, 条件值类型 设为 Code 类型;
【说明】不包含‖区间查询‖但包含‖参照‖， “控件类型”设为 MultiRefTextBox, 条件值类型设为 ID 类型 ; 但 ‖ 制单人 ‖ , ‖ 修改人 ‖ , ‖ 审核人 ‖ 字段的“控件类型”设为 TextComboBox, 条件值类型设为 Text 类型； 【说明】不包含‖区间查询‖与‖参照‖， “控件类型”设为 TextBox, 条件值类型 设为 Text 类型。 整型：
“控件类型”设为 NumTextBox，条件值类型设为 ID 类型。 具体的字段查询设置， 可以查找 eap_SearchPlanItem 表相应字段的预置。 【高级方案】只需要从【从简单方案导入字段】 ，再进行简单修改即可
b、预置报表元数据 打开报表工具，打开一个报表的字段设置界面，点击导入自定义项
按钮，输入 Dto 名称、别 名、输入自定义想数目，点击确定， 自动生成报表元数据。
所有其他相关元数据中 RefDtpProp 的属性一律等于 VoucherName.DtoName.FieldName。 此属性用于更新其他相关元数据的启用状态可见以及同步标题。 由于表头自定义项和表体自定义项也进行分组， 所以需要把分组中的自定义项进行上面 的设置和设置默认不显示(isSystem=1)。
6 特别说明：分级处理
说明：分级预置只针对报表的汇总表与执行表，明细表与帐表不参与分级。
a、基础档案进行了如下处理： 增加了几张表，将原来的递归型
的转换为非递归的数据行 有级次的基础档案
基础档案的部门、费用、收入, 货位、出入库类别、地区档案, 货品分类，往来分类。
如图所示，设置【分级父字段】、【末级字段标识】、【可分级次】
需要【可分级次】 ， 【汇总级次】需求默认为 1，【分级父字段】、【末级字段标识】如果前 面设置好，这里会自动带过来，否则要手工输入，严格区分大小写。
2.7 自由项数据预置
报表预制工具的【字段设置】 加上【关联 DTO 属性】 ，格式为：Eap_EnumItemDTO.FreeItem + 序号。 报表预制工具的【查询 设置】 如果自由项需要分组，需要将分组字段设置的‖系统字段‖栏勾选，已使其在没有启 用的情况 下不显示出来。
【查询工具】 设置【系统字段】 为 true
建立各模块的项目：Ufida.T.【模块编码名称】.Report.UIP；如 Ufida.T.PU.Report.UIP 建立文件，注意命名规范要和报表预置一致，参考各模块代码。 举例： 【进货单统计表】
用来在卡片上显示相应的菜单标题。其返回的 GetMultiLanguageText 方法，是调用基类的 GetMultiLanguageText(string module, string name)封装页面类得到多语的方法。 触发时 机：当进行报表查询，调用页面的基类，完成控制器的分配任务，执行模板类的基类
用于显示报表的表头，要依据需求文档的过滤条件的‖带入报表‖列的显示设置，其中的字段 名字具体是取数据库的表 eap_searchplanitem 的 fieldname 的名称，具体可以查看上述代 码的 CreateSearchContentHeader 方法。 注意： 当用查询预置工具修改了报表带入项字段名称的 时候， 也必须同步修改相应 UIP 页面 的
CreateSearchContentHeader 方法的传入带入项的名 称。 触发时机：当进行报表查询，根据页面的 url 请求类型，找到相应的控制模板类并运行， 初 始化主流程，调用报表模板基类的 BuildReportHeader()方法，构建报表默认头结构，同 时 调用
主要完成对功能权限的判断， url 的重定向， 如果此方法返回 null， 联查的页签就不会打开； 非 null 就返回的 string 数组，所带的参数 destUrl 是联查的 url，destCode 是菜单编码， destTitle 是菜单标题，这几个参数的值是根据报表工具的栏目设置的联查标题、联查提示 预置得到的。 说明：当然，BeforeAssociate 方法的根据 url
检查权限的功能已经在报表模 板基类 DetailAndSumReportTemplateBase 实现了，如果联查的数据是期初单据的内容，这时就需 要加以 区别， 主要是针对 string[]数组的参数取值处理， 因为该数组参数值预置实现的只是 非期初 的情况，期初的情况不能用预置数据体现出来，就需要在相应的 UIP 页面用代码区别 出联查
的单据日期是否小于所用帐套的开账日期，从而联查出期初的单据。 触发时机：当 点击报表的联查，需要得到联查的 url 信息，跳转到 url 指定的页面，显示相 应的数据内容。 具体是根据基类的 Redirect(string url, string code)，检查是否有相应报表 的查看权限， 并根 据报表 uip 继承的 IBeforeAssociate 接口， 返回报表 uip 的
a、报表服务代码主要结构
报表服务（销售模块）的代码目录如下：
下面是最基本的一个主 SQL 的结构。
从上面的代码可以看出报表服务的动态 sql 主要由 5 部分组成 1．select 字段 2．主表以及根据显示字段动态拼接得 left join 表 3．where 条件 4．数据权限控制 5．order by 排序语句 其中关键是两点 (1) 根据显示字段动态拼接 left join 表： 之前的做法是把所有的查询字段和所有相 关联的表都放到主 sql 中， 这样造成很多数据 冗余，
同时导致整个报表 sql 语句执行效率较低。 因为大多数时候用户不会让全部数据显示。 基于这个思想， 现在的 sql 语句尽量做到动态拼接。 就是根据显示字段动态的拼接 left join 所关联的表。 (2) 独立获得的 Where 语句。 之前的 where 由于主 sql 把所有关联的表都进行了“left join||inner join”,所以直
接返回所有查询条件拼接的字符串。而由于 1.1 中描述对字段和 left join 的处理方式， 所以直接返回所有的查询条件拼接的字符串就不适用了。 因为有可能查询条件有的条件， 而 没有相关联的 left join 表。现在的处理方式是，where 不与字段和 left join 表相关联， 独立进行查询。
b、动态 sql 实现方法
（1）预置 selectFieldName 由于之前报表工具没有实现把“字段设置”中“选择字段” 导入到“栏目预置” ，导致 eap_reporttablecol 中”selectFieldName”字段为空。新报表工具已实现该功能。但这里 有一个要提醒大家，就是如果大家之前在“字段设置”中把“选择字段”和“查询字段”都 预置成“字段名称”
，也就是这三个预置数据都是字段的别名。现在用这个工具是不合适的， 因 为 现 在 优 化 方 案 中 动 态 拼 查 询 字 段 ， 而 这 个 字 段 会 用 到 eap_reporttablecol 中
selectfieldname，拼成类似与【selectfieldname】+”as”+【别名】 。如果三个预置数据 都是一样，不符合 sql 语法规则，会报错。 （2）生成字典 由于动态拼 sql,所以需要找到表的别名和物理表之间的对应关系。这样就需要每个报 表针对 sql 生成一个对应关系的字典。字典是这样设计的： <”tableAliasName”, --表的别名 <”
（4）子类要进行的操作 1、 重写两个属性：
//得到查询报表明细的完整的 sql, 这个方法主要是拼主 sql。调用上面介绍的基类
中//两个方法。具体用法大家可以参考“销货单明细表”和“销货单执行表” 。
由于 left join 是根据查询字段进行动态拼接的，所以查询字段的 selectFieldName 是必须有值的，且这个值是必须带”.”的，这样我才可以解析”.”前边表的别名，找到对 应的字典。从而进行 left join 的拼接。否则我无法找到对应的字典。 由于[?]+”.id”都是不可以显示的字段，而这些字段又都是有用的字段，我无法判断
什么时候加和不加。所以我现在的处理方式是统一都加。 现在设计的主表只有一个，也就是只有一个根节点。这样就有一种可能，就是显示字段 只和主表关联。这种情况 left join 就不会关联到表头信息，而数据权限需要用到表头信 息。这种情况就需要大家在返回的 leftTableSql 进行判断了。具体可以参考“销货单明细 表” 。 现对这里用到的一个主要方法参数进行说明一下：
处理的字段。就是有些字段不符合上面的规则，但有时可现实 的字段，我会统一放到这个 集合里。这里有一个特别需要大家会用到该参数的地方。就是如 果该字段是通过报表工具 的输出表达式得到， 我会把所需要的所有字段都放在里边， 如果不 是特殊处理字段。例 如：a=b+c,如果 b、c 不在 specialFields 里，我也会把 b、c 放到 needShowFields 里。
noShowFields，不显示字段。例如执行表中，根据查询条件不同，显示字段不同，可 以通过 这个参数进行控制。
报表在拼动态的 selectField 时，先从特殊字段中查找，如果是特殊字段则加入到 选 择字段中来， 如果不是特殊字段则根据栏目设置来拼查询字段。 如果有些字段并不是某些物 理表的字段，而是通过查询多个表的有关字段组装而来的，因改在报表服务中重载基类的 getSpecialAndNoShowFields（）这个函数，在该函数中写出数据字典
c、字典的设计方法与工作原理
我们设计了这样的字典：
但是对于上面所列出的 sql 中，因为“2 QuantityPrecision”这个字段比较特殊，但不是某 个物理表中实际存在的字段，我们需要对该字段设计一个特殊的字典。
既然字段设计好了，那么根据字典拼写字段和表的过程是怎样的？ 下面的代码简要解释了字 典的工作原理。 1. ReportTableColumnInfo df （根据预置数据初始化栏目信息）
2. 按照先特殊字段后普通字段，得到选择字段的集合，
