MVC3/VoiceXML最佳实践

Question

全部，

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

所以我们从MVC 3和Razor开始新鲜出炉，到目前为止这么好。我已经成功地将几乎所有的处理逻辑移动到控制器，并让大部分VXML只是发出提示并等待DTMF回复。但是，看着很多示例VXML代码，它开始看起来好像在一个页面上使用多个基本路由和VXML内置的DTMF处理和实现可能更简单。更复杂的决策和数据库/服务器访问会像现在这样调用控制器。

我在严格要求逻辑的地方与实际上可能更简单的代码之间存在着分歧。我的VXML印章不是非常先进的（我知道足够危险），所以我正在征求意见。让其他人在页面上使用多种表单？更好或更差？

由于

吉姆斯坦利 黑板Connect Inc.在

Answer 1

选择使用简单的VoiceXML和移动所述逻辑服务器侧是一个相当普遍的做法。下面的优点/缺点。

服务器端逻辑

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

客户端逻辑

• 一般更具伸缩性。 VoiceXML浏览器倾向于使用大量的资源编译和处理页面。一个较大的页面通常会比各种较小的页面做得更好。但是，平台差异显着，您的规模可能会使这一点变得微不足道。
• 使用静态页面的机会更大。许多平台都有高度优化的缓存（不仅仅是获取数据）。如上所述，只有当每个设备有100个端口或1000个端口连接到服务器时，才会有所影响。

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

Answer 2

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

而不是创建一个大的语音XML页面，每个问题的子对话框以及在客户端完成的所有路由，每次收集后回发到服务器，然后找出现在要去的地方。显然这与Jim指出的有关，但希望是从VoiceXML中抽取一些IVR/callflow，并减少对VoiceXML中开发人员的依赖。

我期待在使用MVC3重新开发的基础上，基地IVR功能，可再根据托管的VoiceXML平台上进行修改创造不同的看法：

• 识别
• 提示
• 转移
• CTI获取/设置
• 断开

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

Answer 3

Jim Rush对服务器端与客户端逻辑的优缺点进行了很好的概述，并且与我在我的博客文章“Client-side versus Server-side Development of VoiceXML Applications”中关于此主题的讨论非常一致。我相信把服务器逻辑放在服务器上的优点远远超过把它放在客户端上。 VoiceXML用户组正致力于从版本3.0中删除VoiceXML中的大部分逻辑，并建议使用称为状态图表XML（SCXML）的新标准来处理语音应用程序的控制。我已经开始了一个开源项目，使用ASP.NET MVC 3.0开发VoiceXML应用程序变得更容易，可以在CodePlex and is called VoiceModel上找到它。这个项目中有一个示例应用程序，它将演示保留逻辑服务器端的方法，我相信这大大提高了语音对象的重用性。