ABFrame系统设计开发规范
3） 注意逻辑流中调用的运算逻辑的返回值或抛出异常的情况，针对不同返回或异常可以
提供相应的处理，以保证应用的健壮性。
4） 充分合理利用已有的运算逻辑完成逻辑流的开发，以提高逻辑流处理的效率，以下为
常见的原则：
a) 处理数据库查询时，如果很确定需要查询哪些字段，建议使用查询指定字段的运算
逻辑，而不是查询所有字段的运算逻辑，尤其在相应表包含的字段数很多而且数据量很大的情况下更应遵循本原则； b) 在处理数据库查询时，对于具有海量数据表的操作要求进行谨慎查询处理，避免因
条件范围太宽导致返回数据过多，影响系统资源消耗；
c) 处理数据库查询时，如果直接使用sql处理查询，避免使用“select * from”语句，
建议明确指定查询字段，如“select a,b,c from ...”； d) 在处理迭代的情况时，如果迭代的次数非常大引起处理时间无法满足应用要求的响
应指标，应该考虑进行处理优化（如减少迭代过程中的处理环节等），或者将该部分的逻辑流处理通过运算逻辑实现。
e) 一般情况下，业务处理的逻辑不建议通过运算逻辑实现，但在某种特定情况下，从
平衡效率的角度，需要将业务处理逻辑通过运算逻辑实现，这需要依据经验根据实际情况确定。
f) 在逻辑流实现的处理步骤中，如果某些处理没有顺序上的区分，建议将产生数据量
共61页 第36页
ABFrame系统设计开发规范
大的处理放在靠后的步骤中，这样可以减少数据总线上数据的容量。例如，某个逻辑流实现查询订单的详细信息和订单的物品列表，这两个查询处理在逻辑上没有先后顺序，则建议将执行后产生的数据量大的处理放在后面处理，所以逻辑流实现时，先查询订单详细信息，再查询订单的物品列表。 g) 逻辑流中允许子逻辑流的嵌套调用，但嵌套的层次最好不要超过3层，否则对事务
处理的考虑变得比较复杂，而且嵌套层次太深，会影响执行效率。 h) 注释规范：功能简要说明，输入，输出，关键点说明，例如：
5） 关于逻辑流开发的限制
a) 如果遇到比较复杂的逻辑流，必须要及时和项目组技术负责人沟通讨论后再做决定
（主要是考虑到不同的实现有不同的性能）
b) 每一个逻辑流中必须要有相应的说明（通过使用注释图元，描述逻辑流的功能、数
据接口或者使用限制等等），使用业务术语说明这个逻辑流的业务功能，例如：
c) 多表查询的对策（按优先级排列）： i. 建立EOS查询实体
共61页 第37页
ABFrame系统设计开发规范
ii. iii. iv. 建立数据库视图 建立命名Sql
在逻辑流中拼接SQL
6） 关于处理cra逻辑流
7） 代码字段如何获得对应的代码描述
在查询某些单表的记录时，存在某些代码字段，对应代码的描述存放在另一张业务表中（注意，如果代码是通过业务字典表定义的，不属于本案例的情况），例如，查询员工信息表的结果集中，员工记录中保存的是部门编号，部门编号对应的部门名称保存在部门表中，现在希望显示在页面上的员工信息显示部门名称。
【最优方案】类似这种情况，可以在逻辑流查询单表记录后，针对获得的查询结果，通过调用getCodeDescInEntityList，比较方便而且高效的获取代码字段对应的描述。而getCodeDescInEntity是处理与此类似情景的单条记录Entity的
适用场景：当单表中需要做类似处理的代码字段较少时（<=三个）适于用此方案
【次优方案】通过视图或者查询实体将主表和其他代码描述表关联起来进行查询，这样获得的查询结果中已经包含了代码的描述字段
适用场景：当查询的单表包含多个需要获取描述的代码字段时。
【低级方案】针对查询出的SDO数组进行迭代循环，获得每条记录的代码，然后去查询代码对应业务表中的业务描述。
适用场景：任何情况下绝对禁止采用此方案。
7.2.4.Java构件
ABFrame及相关项目不使用Java构件实现业务处理。
7.2.5.组合构件
ABFrame及相关项目，仅在涉及到系统间存在接口时，使用组合构件。
7.2.6.运算逻辑
1) 首要原则：运算逻辑的开发是受限的
项目组的成员不能随意增加运算逻辑，业务处理尽可能通过在逻辑流中复用已有的运算逻辑来组装，如果自己想增加一个运算逻辑需要和系统设计负责人及时沟通讨论后再做决定（这样做有利于业务与代码的分离，便于逻辑流未来的修改和维护，同时基于java代码实现的运算逻辑，可能会给系统带来诸多隐形的BUG，给系统的稳定运行造成隐患，也不利于系统的后期维护）。
2) 第二原则：尽管不提倡开发过多的运算逻辑，那么什么场景下需要开发运算逻辑呢：
a) 一些没有包含在已有构件库中的与业务无关的原子服务，由于当前项目使用的是
EOS6的试用版本，对于该类运算逻辑，要求由研发支持的接口人提供实现，并提
共61页 第38页
ABFrame系统设计开发规范
交给研发
b) 业务处理中需要调用外部系统或其他第三方产品的接口，需要将这些接口通过运
算逻辑进行封装，例如与第三方系统（如CAS）存在协议的接口处理、调用ESB的接口、调用LDAP认证的接口等等
c) 既有系统已经有一些基础处理的JAR包，其中提供的某些操作在EOS的运算逻辑
中没有，希望通过运算逻辑封装这些操作形成在EOS逻辑流中可以拖拽的运算逻辑（使用EOS6提供放入运算逻辑导入功能）
d) 系统中存在某些业务处理需要对大量业务数据进行汇总统计，或者针对一个很大的
查询结果（超过1000行以上）进行迭代处理，而迭代处理中涉及大量的操作。
3) 编写运算逻辑时，要求填写完整相应描述信息，包括运算逻辑的描述及参数的描述 4) 运算逻辑原则上建议不抛出异常，而是通过捕捉异常后设置返回值返回，异常信息可以
通过日志接口记录到日志文件中。如果抛出异常，要求能在构件对应的文档中明示抛出哪些异常，建议不要抛出基类异常。
5) 在运算逻辑中如果存在多处错误返回，应根据不同错误返回不同返回码（如-1、-2、
-3……），这样有助于进行错误定位。
6) 运算逻辑中有关调试、出错提示等，一律使用EOS平台发布的日志记录接口，详细用
法参见EOS6的日志接口文档。
7) 一般情况下，运算逻辑正常返回值为1；返回负值表示捕捉到异常或因数据不合要求导
致处理中断，需要进行分支处理；返回0或其他正数表示处理完成，但可能存在某些警告信息，例如用expandEntity查询指定条件的某条记录时，可能符合查询条件的记录有多行，则返回第一行记录，而返回值为记录行数。 8) 运算逻辑参数项设置原则：
a) 原则一：对于可以设置多组参数的运算逻辑，最后一个接口参数，在类型后面增
加…，表示在调用运算逻辑时，可以动态增加参数的个数，例如String…，Date… b) 原则二：不建议运算逻辑设置太多参数项（对于支持多组参数的除外），如果参数
项超过5个，建议充分利用SDO对象，通过Entity的节点方式处理，例如发送邮件的运算逻辑sendMail，将整个邮件信息（如发件人、收件人、抄送人、主题、内容、附件等等）放入一个SDO对象中以一个参数传入，而不是每项作为一个参数传入，在运算逻辑中通过取SDO对象的属性获得各项参数。
9) 运算逻辑是通过JAVA代码实现的，JAVA代码的编写请参考有关JAVA代码编写规范
的资料。
10) 关于运算逻辑中事务处理的建议：
建议在运算逻辑中尽量不使用事务处理，而是将事务的控制放到调用运算逻辑的逻辑流中（通过事务图元进行控制），这样避免因为运算逻辑和逻辑流中事务使用混乱导致出现事务一致性的问题。
注意事务中的数据库操作时间不要过长，因为事务会锁表，时间过长，别的连接对同一表操作会长时间等待，而且可能以为因为锁冲突导致死锁。本注意事项可能与上面的建议发生冲突，例如在运算逻辑中因为操作数据库比较多事务时间必然较长的时候，还是需要在运算逻辑处理事务。
11) 不要在运算逻辑方法中使用流，在datacontext尽量避免用流，防止未知异常导致流无法
正常关闭！（王克强的建议） 12) 关于运算逻辑中数据库操作的建议： 待补充……
13) 注释规范：功能简要说明，输入，输出，关键点说明，例如：
共61页 第39页
ABFrame系统设计开发规范
7.2.7.页面流
1) 编写的页面流要求以业务的语义表达每个处理环节（避免出现程序语义或者不描述），
同时逻辑图形编排清晰，尽可能不出现交叉线，另外要求在页面流中增加注释图元，注明页面流的功能等，这样有利于别人的阅读和理解，也方便的日后系统的维护，以下是某项目中的页面流截图：
2) 页面流的图形应该简单明了，如果一个页面流上面出现超过20个以上的图元(不包含开
始和结束图元)，则需要考虑该逻辑是否应该优化，如判断是否处理繁琐冗余，是否可以变为多个页面流，是否调用的逻辑流粒度太细等。 3) 考虑逻辑流调用的返回值，针对非正常的返回要有统一的出错处理（如定位到统一的错
误页面等）
4) EOS6中支持在页面流中调用运算逻辑，为了项目中层次清晰，原则上不建议在页面流
中调用运算逻辑，尤其禁止在页面流中调用对数据产生更新的运算逻辑。而是将该类操作封装在逻辑流中，页面流调用逻辑流的方式 5) 页面流对于Session数据的处理原则：
a) SessionContext数据将在会话期间占用内存，只适合保存会话期间的全局数据，尽
可能避免在会话数据中存放过多数据量 b) 对于MUO对象，由于会自动复制到requestContext和bizContext，更加需要控制存
放的数据大小。
共61页 第40页