MVC3 / VoiceXML最佳实践

Question

所有

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

所以我们从MVC 3和Razor开始，到目前为止一直很好。我已经成功地将所有处理逻辑移动到控制器，只是让大多数VXML只是发出提示并等待DTMF回复。

但是，看一下大量的VXML示例代码，开始看起来在页面上使用多个进行基本路由和VXML的内置DTMF处理实际上可能更简单。更复杂的决策和数据库/服务器访问将像现在一样调用控制器。

我想要严格控制逻辑的位置与实际上更简单的代码之间存在分歧。我的VXML排队并不是非常先进（我知道这很危险），所以我正在征求意见。让其他人在页面上使用多个表单吗？好还是坏？

由于

吉姆斯坦利 Blackboard Connect Inc.

Answer 1

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

服务器端逻辑

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

客户端逻辑

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

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

Answer 2

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

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

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

• 识别
• 提示
• 转移
• CTI Get / Set
• 断开

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

Answer 3

Jim Rush对服务器端与客户端逻辑的优缺点进行了很好的概述，与我在博客文章“Client-side versus Server-side Development of VoiceXML Applications”中对此主题的讨论非常吻合。我认为将逻辑放在服务器上的优点远远超过将其放在客户端上。 VoiceXML用户组正在逐步从版本3.0中的VoiceXML中删除大部分逻辑，并建议使用名为State Chart XML（SCXML）的新标准来处理语音应用程序的控制。我已经开始了一个开源项目，以便使用ASP.NET CodePlex and is called VoiceModel上的ASP.NET MVC 3.0更容易地开发VoiceXML应用程序。这个项目中有一个示例应用程序，它将演示一种保持逻辑服务器端的方法，我相信这会极大地改善语音对象的重用。