模型视图控制器体系结构中服务请求的(宏)记录器

我们正在重构基于GUI的测试应用程序 用于无线电设备,并重写Python. 新的体系结构将基于 模型视图控制器模式,如下: 用户输入 | v +----------------+服务请求服务请求+--------------------+ | acontroller + -------------------- + + --------------------- + atestscript | + -----------------+ | | +---------------+ v v +---------+更新+------------------------+ | Aview | <--------------+ AmodelObject | +---------++-------------------------+ ^ | v 测验设备 在交互式模式下,用户生成刺激并执行 使用控制器通过GUI测试的设备上的测量 对象. 控制器对象将服务请求发送到模型对象 实际工作的位置. (数据)模型的变化 对象通过视图对象可视化. 到目前为止什么都没有特别;-) 为了自动化测试序列,用户还可以编写测试 脚本(在Python中),向模型对象发送类似的请求 (也用Python编写). 这应该像 可能,因为用户不是软件开发人员. 例如, 用户通常不必担心模型的创建 对象? 这些通常是创建的(在用户的全局名称空间中) 在初始化时(基于配置文件)或交互式 使用工厂(也是模型对象). 此外,我们还需要记录服务请求 由用户输入以交互式模式产生,以"重播" 后来 - 换句话说,一种宏观录音机. 录音 应该以python脚本的形式进行编辑 其执行. 记录服务请求很重要,而不是 用户与控制器对象的交互. 自然只有 源自控制器对象的请求应截获,并且 记录. 对于记录机制,我们有两个截然不同的想法: 1.控制器对象将请求作为文本字符串发布, 评估以执行实际的服务请求 调用. 然后可以拦截这些文本 记录. 2.使用拦截器(请参阅线程'Python Interceptor软件包' 2004-06-16)拦截模型的方法调用 对象. 然后,拦截器从 用户的全局名称空间(请参阅"导入到指定的" 命名空间'2004-09-08),分析呼叫参数和 重建调用的文本表示 (在将调用委派给实际方法之前). 两种方法都有优势和缺点,我们可能没有 请参阅所有含义. 有人有这种机制的经验吗,还是可以指出我 相关文献或(甚至更好)采用开源项目 这种机制(最好是在Python中)? 提前致谢 弗里茨