1

全部，

我目前正在改进使用带有 VXML 2.0 的经典 ASP 编写的古老 IVR。相信我，这是一团糟，主要是由于 ASP 代码和 VXML 逻辑之间的路由逻辑混合，具有多个回发，如 ASP.NET。调试不好玩。

所以我们从 MVC 3 和 Razor 开始，到目前为止一切都很好。我已经成功地将几乎所有的处理逻辑转移到控制器上，让大部分 VXML 只是发出提示并等待 DTMF 回复。

但是，查看大量的 VXML 示例代码，开始看起来使用页面上的多个和 VXML 的内置 DTMF 处理和 . 更复杂的决策和数据库/服务器访问将像现在一样调用控制器。

我在希望严格控制逻辑的位置与实际上可能更简单的代码之间感到左​​右为难。我的 VXML 印章不是非常先进（我知道足够危险），所以我正在征求意见。其他人是否在一个页面上使用了多个表单？更好或更差？

谢谢

吉姆斯坦利黑板连接公司

4

3 回答 3

1

选择使用简单的 VoiceXML 并移动逻辑服务器端是一种相当普遍的做法。下面的优点/缺点。

服务器端逻辑

  • 如果您还执行输入验证（对语法有效，但对主机或其他验证逻辑无效），通常很难让重试计数器按照您想要的方式执行
  • 用于进行逻辑描述的更好的编程语言/工具包（我不是 JavaScript 的粉丝，但即使你喜欢 JavaScript，你也往往不得不创建很多表单来获得你想要的流控制）。
  • 通常更容易调试。逐步执行逻辑决策并访问日志记录工具。
  • 通常更容易创建使用参数来改变组件行为的可重用组件。

客户端逻辑

  • 通常更具可扩展性。VoiceXML 浏览器倾向于使用大量资源来编译和处理页面。一个较大的页面通常会比各种较小的页面做得更好。但是，平台差异很大，您的大小可能会忽略不计。
  • 使用静态页面的机会更大。许多平台都有高度优化的缓存（不仅仅是获取的数据）。只有当您每台设备有 100 个端口或有 1000 个端口访问服务器时，上述情况才有意义。

在有人请求某种全局行为改变之前，混合和匹配并不坏。您可能会在多个地方进行更改。调试技术也会有所不同，因此可能会使您的支持路径复杂化（例如，查看浏览器日志与服务器日志以查看通话中发生了什么）。

于 2011-08-17T00:44:52.060 回答
1

我们当前的框架目前混合使用服务器和客户端。我们所有的逻辑都在 VoiceXML 中，服务器用于状态保存和生成识别组件。不幸的是，由于我们所有的逻辑都在 voicexml 中，这使得单元测试变得更加困难。

与其创建一个大型 voicexml 页面，对每个问题和所有在客户端完成的路由进行子对话框，不如在每次收集后回发到服务器，然后确定现在去哪里。显然，正如 Jim 指出的那样，这有其优点/缺点，但希望是从 VoiceXML 中抽象出一些 IVR/callflow，并减少对 VoiceXML 开发人员技能的依赖。

我正在考虑使用 MVC3 重新开发，基于基本 IVR 功能创建不同的视图，然后可以根据托管 VoiceXML 平台对其进行修改：

  • 认出
  • 提示
  • 转移
  • CTI 获取/设置
  • 断开

我仍在研究的是如何在 MVC 中创建可重用的组件。是否创建子对话框并返回结果（类似于我们当前的操作方式），或者重定向到通用控制器，然后在控制器完成后重定向到“已完成”操作。

于 2011-10-24T06:53:08.593 回答
0

Jim Rush 很好地概述了服务器端与客户端逻辑的优缺点，并且与我在博客文章“ VoiceXML 应用程序的客户端与服务器端开发”中对此主题的讨论非常一致。我相信将逻辑放在服务器上的优点远远超过将其放在客户端上。VoiceXML 用户组正朝着在 3.0 版中从 VoiceXML 中删除大部分逻辑的方向前进，并建议使用称为状态图 XML (SCXML) 的新标准来处理语音应用程序的控制。我已经启动了一个开源项目，以便更轻松地使用 ASP.NET MVC 3.0 开发 VoiceXML 应用程序，该应用程序可以在CodePlex 上找到，称为 VoiceModel. 这个项目中有一个示例应用程序，它将演示一种保留逻辑服务器端的方法，我相信这会极大地提高语音对象的重用性。

于 2011-12-09T19:47:04.203 回答