|
|
|
|
EOS项目代码检查后的问题小结
发布时间:2006-05-08 00:00:00 作者:cservice 出处:goComDevCenter 语言:中文 阅读次数:1544次 |
| 如何才能用好EOS？对于这个问题也是仁者见仁，智者见智。最近参加了两个项目的代码检查，发现一些共性问题，在这里和大家分享一下。
A、在同一个业务逻辑中，尽量不出现多次使用同一个运算逻辑的情况：对于类似于BL_setNodeValueBatch、BL_createEmptyNode等运算逻辑，能合并的尽量合并；
B、以尽量少的运算逻辑的组合完成业务功能：这样可以避免出现复杂的连线，使业务逻辑不容易阅读；
C、业务逻辑中运算逻辑之间的连线尽量简单、尽量不出现交叉线：对于复杂的业务逻辑，考虑将业务逻辑拆分成几个子业务逻辑。而且在拆分的同时考虑拆分出来的子业务逻辑是否能被别人复用；
D、如果需要针对总线中的一个节点做操作，一般不需要使用BL_createEmptyNodeBatch运算逻辑创建空节点：EOS总线处理有一个原则，一旦开发人员要操作的节点不存在，EOS会自动创建该节点。但是，当指定BL_queryEntity运算逻辑需要操作的字段时除外。
E、在操作数据库的时候，尽量用数据实体映射的方式：尽管EOS提供了直接拼装SQL语句、运行SQL语句的运算逻辑，但是，EOS并不鼓励这种操作数据库的方式，因为会失去快速适应需求变化的优势。举个例子，如果你采用拼装SQL语句的方式操作数据库，一旦需求变化，如需要在页面增加一个查询条件，除了要修改Jsp页面，你还需要在业务逻辑中判断用户是否在查询时输入了这个条件，一旦输入，还需要将这个条件加入到SQL语句中。如果使用数据实体映射的方式则不存在这个问题。
F、对于多表查询，EOS鼓励使用查询类型的数据实体：查询类型的数据实体类似于在数据库层建立视图。有些开发工程师在开发环境中运行、调试查询类型的数据实体时感觉很慢，其实这是由于Studio每次运行时会重新加载这个数据实体，大部分的时间都耗费在加载数据实体的过程中。而运行环境则不会出现这个问题，所以大家可放心使用。
G、对于一些中间查询结果，尽量使用BL_queryEntity运算逻辑：在实际操作中，有的开发工程师习惯使用DataQueryExt逻辑类中的运算逻辑：其实DataQueryExt运算逻辑类中的运算逻辑主要用于处理利用QueryForm页面控件提交到服务器的查询条件，主要用于处理复杂查询，总线中的实体结构相对复杂些，而中间查询的条件通常都不是非常复杂。
H、对于一次更新多条记录的情况，可以使用BL_updateCriteria运行逻辑完成：具体使用方法请参考EOS Studio的在线帮助文档。BL_updateCriteria运算逻辑和BL_updateEntity运算逻辑的最大区别就在于：前者的更新条件和更新字段是由开发工程师自己指定的；而后者的更新条件是该实体所映射的数据库表的主键，更新字段由开发工程师自己指定。
I、当判断数据库表中是否具有满足条件的记录时，使用BL_count运算逻辑：具体使用方法请参考EOS Studio在线帮助文档。
J、重视业务字典的应用：对于一个业务代码对应一个业务描述（比如用1表示男性，2表示女性）的情况，一般在实际的数据库表中存储的是代码，而在页面则需要将代码翻译成描述，EOS提供了利用Jsp Tag来将代码翻译成描述、将业务代码－描述生成为select、radio等。具体使用方法请参考EOS Studio在线帮助。
K、每个业务逻辑都需要有业务描述、开发者等注释信息：这样有助于系统维护。
L、谨慎使用带“All”字样的运算逻辑：避免在数据总线中产生不必要的节点。
M、关于日期时间的格式：EOS默认处理格式为yyyyMMdd HH:mm:ss，若要使用其他格式，请参考gocom.primeton.com上的相关文章。
N、对于业务逻辑中的各运算逻辑图标的排列，需要遵循一下两个原则，以便利用EOS Studio生成漂亮的实施文档：
1、要做到“横平竖直”：尽量不出现斜线、交叉线。有斜线的地方尽量将连线拖拽成折线。
2、在Studio的业务逻辑编辑器最大化后，所有图标尽量在一个屏幕的范围类排列完成。 |
|
| 声明：本栏目转载文字、造型、样式、图形及程序如有来自网络，版权归原作者或首发媒体所有，欢迎任何个人访问或者转载，若有作者及出处有误，请来信说明，我们将及时更正。 |
|
