元数据是支撑框架运行的基础。定义元数据、发布元数据、在发布代码中添加业务逻辑成为当前开发工作的基本模式。在应用架构中，各业务功能需要重点处理的是UI与EJB组件的逻辑。BOS集成开发环境与应用框架类库为实现这两个任务提供了很大的便利。基于BOS和应用框架的开发流程主要由四个步骤组成：设计业务对象、调整数据库结构、设计查询对象、设计界面。 2.2.1. 设计业务对象
我们可以从Together的设计模型中导出BOS业务对象，也可以在BOS中手工定义。一般来说，详细设计模型中的一个“实体类”对应一个BOS业务对象。下图展示了定义一个业务对象的大致过程：
KINGDEE DOC ID：KDSP_EAS_T_V3.0.0 软件构架设计文档 第 7 页 共 31 页 在定义一个业务对象前，应该详细分析它的特征，在应用框架中选择合适的基类，这样定义出来的业务对象就具备了一些典型业务的逻辑，例如从DataBase继承的业务对象自动具有新增、保存等基本功能。有关应用框架类库体系的介绍，详见《应用框架编程制南》。 业务对象的继承分抽象继承与非抽象继承两种。两者的区别在于数据存储结构不同，在业务逻辑上没有区别。前者将基类属性存储到子类对应的表，后者将基类属性存储到基类对应的表。
业务对象的属性分为两种：自有属性与连接属性，后者是与其它业务对象关联的属性，在建立连接属性前必须先定义对象间的关系。有两种特殊的自有属性须特别注意：一种是枚举类型，详见TODO；另一种是多语言属性，当指定某属性为多语言后，BOS发布工具将为该属性生成多个字段，每个字段对应一种语言，ORMapping会根据当前系统语言确定存取哪个字段。
业务对象可以拥有一个逻辑主键，主键是对象的唯一标志，由若干个属性组成。必须注意的是，在某些特殊场合下，例如只批量地更新或查找，不操作单个记录，我们不应该额外地去设置一个逻辑主键，否则将给批量操作带来很多麻烦。
定义业务方法时应根据该方法执行的操作正确设置事务属性，通常将只进行查询操作的方法设置为“Supports”，否则为“Required”。若该方法须抛出业务异常，则在异常列表处添加EASBizException声明。 根据需要，我们可能配置一些业务对象类及其属性的扩展属性，这些扩展属性用于实现编码规则、BOTP、权限等功能，详细列表请参见TODO。 一个业务对象发布后将生成协议类、远程与本地接口、EJB组件类，以及用于部署的组件描述符。我们可以在EJB组件类中编写业务逻辑。 2.2.2. 调整数据库结构
业务对象相关的表可以用BOS的“实体导出为表”功能创建，但默认生成的存储结构不是非常合理，需要手工调整。 首先，根据“$/KDSP3.0/PDSP-EAS/过程&指南/2_G_设计指南_数据建模规范.doc”调整表名、字段名、主键名、索引名、外键名。其次，根据字符型字段将要存储的数据选择是否支持Unicode以及字段长度等。最后，根据需要增加索引，以提高程序运行效率。 2.2.3. 设计查询对象
BOS提供的查询对象为实现一些简单的查询提供了很大的便利。查询对象可以与F7控件、通用过滤排序对话框、列表界面直接绑定，只需写少量代码就可以完成一个基本的业务功能。 查询对象的字段可以由主对象及其子对象的属性导入，也可以定义成计算式。对于专用于F7控件的查询对象，一般要定义它的默认排序条件。如果要支持虚模式取数，查询对象还须定义一个主键。在执行虚模式查询时，程序首先得到一个主键列表，之后的查询都将直接通过主键而不是原始过滤条件查询，此方式大大提升了分页性能。
KINGDEE DOC ID：KDSP_EAS_T_V3.0.0 软件构架设计文档 第 8 页 共 31 页 查询对象及其属性都有相关的扩展用于实现F7查询、通用过滤排序等功能，详见TODO。
2.2.4. 设计界面
对应于服务端组件，UI在应用框架中也有一整套典型业务的基类，设计界面前应该选择合适的基类。为适应不同的显示分辨率，界面通常采用KDLayout布局。人机界面规范（http://uiserver/Guide/EAS/index.htm）对控件的选择、排列、规格等都作出了明确规定，建议一开始就严格遵守界面规范，以免后期返工。 界面可以是一个空容器，也可以与业务对象或查询对象绑定。一般来说，编辑性质的界面与它操作的业务对象绑定，而序时簿性质的界面与一个查询对象绑定。绑定后的界面会自动根据对象属性类型分配不同的控件，并添加装载与保存的代码。
设计期的一个重要任务是定义Action，每个Action可能与界面的菜单、按钮或快捷键对应，用户对界面元素的操作将触发不同的Action事件。BOS将Action的功能作了扩展，不仅用它来控制相关界面元素的状态，而且将它与权限控制（详见TODO）、工作流（详见TODO）等基础服务联系起来，以一种可配置的方式提供基础服务。
2.3. 小结
本节简要地介绍了EAS的应用架构以及开发的基本流程，目的是给初学者一个整体的映像，明确在开发过程中的主要任务以及框架运行的基本原理。后面的章节将以一个实例详细地描述开发流程的各个方面，包括打印、工作流等高级应用。
3. 基本编程模型与操作过程 下面通过
3.1. 样例需求简要描述
本节为了重点是说明开发技术，选择了一个相对简单的需求：实现一张单据的维护功能，该单据可以在序时簿中查找、过滤，具有新增、修改、删除等基本功能，支持打印与打印预览，单据提交后经过多级审批到达工作流结束点。通过这些实现来描述EAS的基本编程模型和操作过程。 单据头属性列表： 名称 公司 单据类型 编号 业务日期 类型 业务对象 枚举 字符串 日期 描述 单据所属财务组织，默认为当前公司 只有两种类型：甲、乙 单据的编号。为简单起见，由用户输入，系统保证编号不重复。 说明业务发生的日期 KINGDEE DOC ID：KDSP_EAS_T_V3.0.0 软件构架设计文档 第 9 页 共 31 页 制单
单据体属性列表： 名称 摘要 科目 金额
业务对象 类型 字符串 业务对象 数字 单据创建者，默认为当前用户 描述 用户可以选择或直接输入 可以选择，按单据头公司隔离 本位币金额，需处理币别精度，提供千分号 3.2. 准备阶段
（1） 从\\\\192.168.16.62\\eas4.1 下拷贝setup.bat执行，安装开发环境；
（2） 执行W:\\admin\\pt.bat更新最新的日构件，将W:\\eas\\deploy\\apusic\\metas.jar解压到
W:\\apusic\\metas目录下，然后修改配置文件： i. W:\\eas\\deploy\\apusic\\bosconfig*.xml
ii. W:\\eas\\deploy\\client\\config.xml
（3） 从192.168.16.5/bos3.0上Check out整个eas工程，并且在BOS透视图中作为解决方案打开，并且设置解决方案的属性：
如此设置后，程序运行时将从W:\\apusic\\metas目录下读取最新发布的元数据。
（4） 新建一个Java工程，取名为sample，建立一个src目录用于存放源文件，classes目录为输出
路径，并且将classes路径加入W:\\eas\\dev下的配置文件server-user.liblist。这样，程序运行时将优先读取工程最新编译的类文件，而不是部署包。工程依赖的包统一放置于W:\\eas\\lib\\debug。
3.3. 实现一个单据编辑功能
3.3.1. 元数据建模
参照前一节“基本开发流程”的描述，我们需要进行四个步骤的建模。
3.3.1.1. 定义业务对象—单据头
经过详细设计阶段，我们可以分析出该功能有一个唯一的实体类—单据，查找应用框架类层次，
KINGDEE DOC ID：KDSP_EAS_T_V3.0.0 软件构架设计文档 第 10 页 共 31 页 发现BillBase这个基类最适合派生，因为它包含了单据共有的一些属性，而且提供了单据的一般操作方法。选择基类点击确定后，我们可以得到如下的类信息：
注意：由于控制器相关的类将被部署在服务端，所以将它放在app包中。我们可以手工输入表对象的名称，该表不一定物理存在，在使用“实体导出为表”时，BOS将根据表对象名称新建或覆盖数据表。
3.3.1.1.1. 定义属性
切换到第二个页签“属性”，我们发现大多数单据头属性基类都已经提供，只需要额外定义一个枚举类型的属性“单据类型”。我们首先定义一个枚举对象：
该枚举类将被业务对象的协议类引用，所以必须定义在com.kingdee.eas.sample包下，部署程序会将该包下的类同时发布到服务器与客户端。
之后就可以基于枚举对象定义“单据类型”属性了，如图：