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上找到它。這個項目中有一個示例應用程序，它將演示保留邏輯服務器端的方法，我相信這大大提高了語音對象的重用性。