MVC3/VoiceXMLベストプラクティス

Question

すべて

現在、Classic ASPを使用してVXML 2.0で書かれた古代IVRを改良しています。私が信じているのは、ASPコードとVXMLロジック間のルーティングロジックが混在していることが主な理由であり、ASP.NETの複数のポストバックを特徴としています。デバッグするのは面白くない。

私たちはMVC 3とRazorで新鮮になっています。私はかなり多くの処理ロジックをコントローラに移し、VXMLのほとんどをプロンプトに表明してDTMF応答を待つだけで成功させました。

しかし、多くのサンプルVXMLコードを見てみると、ページ上の複数のページとVXMLの組み込みDTMF処理とを使用して基本的なルーティングを行う方が実際に簡単なように見え始めています。より複雑な意思決定とデータベース/サーバーへのアクセスは、現在のようにコントローラを呼び出すでしょう。

ロジックがどこにあるのか、実際にはよりシンプルなコードであるのかという厳しい要求にこだわりました。私のVXMLチョップはあまり進んでいません（私は危険であると十分知っています）ので、私は入力を求めています。他の人がページ上で複数のフォームを使用したことはありますか？良くも悪くも？

おかげ

ジム・スタンレー 黒板接続株式会社

Answer 1

シンプルなVoiceXMLのを使用するように選択すると、論理サーバ側を移動するには、かなり一般的です。以下の長所/短所。

あなたも（文法のためではなく、ホストまたは他の検証ロジックのために有効な）入力検証を実行している場合、あなたが望む方法を実行するために再試行カウンタを取得するためにサーバー側のロジック

• がしばしば困難
• 論理記述を作成するためのプログラミング言語/ツールキットの改善（私はJavaScriptのファンではありませんが、JavaScriptが好きでも、必要なフローコントロールを得るためにはたくさんのフォームを作成する必要があります）。
• 通常、デバッグは簡単です。論理的な決定とログツールへのアクセスを実行します。
• 通常、パラメータを使用してコンポーネントの動作を変更する再利用可能なコンポーネントを作成する方が簡単です。

通常よりスケーラブルなクライアント側のロジック

• 。 VoiceXMLブラウザは、ページのコンパイルと処理に多くのリソースを使用する傾向があります。 1つの大きなページは、通常、さまざまな小さなページよりも優れています。しかし、プラットフォームは大きく異なり、サイズによっては無視できます。
• 静的ページを使用する可能性が高くなります。多くのプラットフォームでは、高度に最適化されたキャッシュ（フェッチされたデータ以上）があります。上記のように、デバイスあたり100ポートのポート、またはサーバーに接続する1000ポートのポートがある場合にのみ重要です。

誰かが何らかのグローバルな動作変更を要求するまで、混合とマッチングは悪くありません。複数の場所で変更を行っている可能性があります。デバッグ方法もさまざまです（たとえば、ブラウザログとサーバーログを見て、通話の状況を確認するなど）、サポートパスが複雑になる可能性があります。

Answer 2

現在のところ、現在のフレームワークでは、サーバーとクライアントが混在しています。すべてのロジックはVoiceXMLにあり、サーバーは状態の保存と認識コンポーネントの生成に使用されます。残念ながら、私たちのロジックはすべてvoicexmlに含まれているため、単体テストが難しくなります。

各質問ごとにサブダイアグラムを作成し、クライアント側で実行されたすべてのルーティングを作成する代わりに、各収集後にサーバーにポストバックして、今すぐどこに行くのかを検討します。 Jimが指摘しているように、これは賛否両論だが、VoiceXMLのIVR/callflowの一部を抽象化し、VoiceXMLの開発者のスキルアップへの依存度を減らすことが望まれる。

私は、ホスティングのVoiceXMLプラットフォームに基づいて変更することができますベースのIVR機能に基づいて、異なるビューを作成し、MVC3を使用して再開発で探しています：

• 認識
• プロンプト
• 転送
• CTIを取得/設定
• 外し

私がまだ取り組んでいるのは、MVC内で再利用可能なコンポーネントを作成する方法です。サブダイヤログを作成して結果を返すか（現在の方法と同様）、汎用コントローラにリダイレクトしてから、コントローラが完了したら「完了」アクションにリダイレクトするかどうかを指定します。

Answer 3

ジムラッシュは、サーバー側とクライアント側のロジックの長所と短所を十分に把握しており、ブログ記事 "Client-side versus Server-side Development of VoiceXML Applications"のこのトピックに関する私の議論とほぼ一致しています。私は、サーバー上のロジックをクライアントに置くことよりもはるかに重要だと考えています。 VoiceXMLユーザーグループは、バージョン3.0のVoiceXMLからこのロジックのほとんどを削除し、ステートチャートXML（SCXML）という新しい標準を使用して音声アプリケーションの制御を処理することを提案しています。私はCodePlex and is called VoiceModelにあるASP.NET MVC 3.0を使ってVoiceXMLアプリケーションを開発しやすくするオープンソースプロジェクトを開始しました。このプロジェクトには、ロジックサーバー側を維持する方法を示すサンプルアプリケーションがあります。これは、音声オブジェクトの再利用を大幅に改善すると考えています。