|
|
原帖由 dayspring_chen 于 2011-2-16 10:06 发表 ![]()
-----------------------------------------------------------------------------
你相当于做了一个报表工具，这里使用动态SQL是不可避免的。
至于这个业务规则引擎，现在做到哪一步了？你不妨拿些简化的例子出来讨论一下。必须承认做这类东西对一个爱动脑筋的程序员是很有诱惑力的，但是结局一般都不乐观：
1. 随着需求的深入，抽离的业务逻辑越来越灵活，到最后你相当于发明了一种语言，这种语言世界上只有几个人能懂。配置元数据比写程序还复杂，比程序还更看不懂。
2. 一不小心没配置好，这个规则引擎就会产生怪异的行为。
3. 配置的组合是无限的，但是你只能对其中的某些做测试，其他的只好听天由命。
4. 引擎部分的代码极其抽象，作者要能知道它会生成什么代码，那些生成的代码又是如何运作的。到最后只有作者本人能够维护这个引擎，其他人不敢动。
5. 有很多临时产生的需求，来不及修改殷勤，就采用元数据+客户化代码的方法。到最后, 客户化代码越来越多，因为大家发现这是解决问题的最佳方法！
-----------------------------------------------------------------------------------
嗯，newkid说的很对，这是开发这类基于元数据变成必须控制的地方，即规则的复杂程度及处理规则引擎的复杂程度。
不要忘记我也是一个玩了oracle十几年的人了。从95年开始玩起的。
1.最早做的是一个接口程序
就是约定传输的业务表单格式串，依据规则进行解析，分解成主从的结构的insert语句，支持字段级、记录级、表单级规则校验，支持主键自动生成。最早做的是插入操作，后来扩展到更新和删除的业务支持。
这个项目的场景上有一个核心系统支持数据采集，但后来需要支持多种外部方式的数据插入（网上申报、ocr之类的）。当时设计的元数据结构还是覆盖全面的，基本上交易系统的规则都能够覆盖到。维护的话也还好，对SQL、PL/SQL熟悉的人培训个一周就可以维护了。
当时还是oracle7，动态sql用dbms_sql搞定，状态信息用raise_application_error传递，呵呵。
2.后来做了一个基于j2ee的三层架构的通用查询
做过通用查询的都知道，这玩意可很难。最典型的问题是：因为需要处理一个条件需关联一个表，因为关联这个表必须用外连接；主关联从表导致主表的记录数被成倍放大（最糟的是笛卡尔集），汇总统计的主表数据出错；条件数过多的时候拼接的sql已经无法理解，条件和条件间互相影响（机构、时间？），结果和结果间互相影响，条件和结果间互相影响；条件集和结果列无非同一数据集时很难处理等。
这个我确实等于自己创造了一套理论，将这些都解决了。而且还实现了：业务复合时间支持（如支持年、半年、季度、月份的复合处理），条件集的SQL优化（包括条件位置的多点替换），结果集通过外连接支持样式套表打开。
最大的查询包括4000多的条件和结果组合，都工作和管理的很好。我已经可以放心让手下人进行维护。也曾和oracle的技术人员进行交流，他们对这种处理也很认可，只是感叹这个唯一的不足是只支持oracle。
3.后来做了一个基于j2ee的三层架构的通用报表
报表显示等是基于润乾的。在润乾之外包装了一层管理层，将报表分为按版本（有效起始终止日期的）划分的子报表，每个子报表有自己的时间、机构等级、前后台、生表前条件校验、生表后特殊处理、报表确认审核、报表回退、报表模板设置。后台调度生表使用的是job，表结果存储最初使用的是clob的xml，后来一时糊涂改成了nest table，最近在考虑要不要改成json。
总体上这个东西做的还可以，满足客户要求和扩展性都还好，汇总表、表间取数、平衡审核、转换总局之类的都是用存储过程实现维护在代码表中，无论开发效率还是运行运行效率都很高。
4.那个业务规则引擎是我再总结当前交易系统弊端加上对以前用存储过程开发进行反思后考虑的。
首先有以前做通用接口的经验，有些思路可以借鉴。而且现在技术手段比以前丰富多了。
当然需要处理以前没有的一些东西，例如webservice、restful等。碰到困难是一定的，但工具就是在应用中磨出来的。至于抽象的粒度及设置的复杂性、覆盖广泛性，必须是设计的人去权衡利弊，进行取舍的。
当前系统主要苦于：开发人员大部分是java背景的，结果是后台数据结构一团糟，新来业务需求，项目经理往往是新建一套表，导致后台数据不优化，数据利用时必须再另写转换规则进行加工；
企业级系统的特点是表单多，表单规则复杂，表单随着客户的业务要求，在极短的开发时间内完成修改，且变化的表单前后业务还有很多制约要求。（呵呵，有点像缓慢变化维，可以叫缓慢变化表单）
开发人员耗费了很大精神在中间层上，用javabean模拟表进行业务逻辑操作。结果是中间的业务逻辑越写越复杂，前台UI客户不友好，后台数据结构BI开发不友好。感觉项目的开发工作没有用在合适的地方。
至于那个引擎，打算今年开始动手实践，先找个适中的项目做实验。至于你提到的那些副作用，当然很感谢提醒，我也会尽力避免。在功能、灵活性、可维护性间取得平衡。绝不会一意孤行，自取灭亡的。
做元数据设计，1000个架构师可能有1000种设计法，戏法人人会变，各有巧妙不同的。
原来是前辈，肃然起敬！你说的这些东西我多少都玩过一点，现在我已经返璞归真，对“通用”的东西都存有戒心。现在动态查询我还经常做，其他的最多采用代码生成器的思路，需要什么就做什么，不指望搞出什么引擎。祝愿你成功！如果有实例请到这里分享。
关于通用查询，有几点可以讨论：
因为需要处理一个条件需关联一个表....
可能好几个条件合起来关联一个表，重复关联必须去除。
因为关联这个表必须用外连接.....
如果条件在被连接的表上，绝对不用外连接。外连接用于从其他表取输出列，比如要把ID转换成名称。
主关联从表导致主表的记录数被成倍放大....
连接键一定要用从表主键就不会发生。 |
|
楼主: newkid
IP卡
狗仔卡
发表于 2011-2-16 17:24
显身卡
楼主
