Лучшие практики MVC3 / VoiceXML

Question

All

В настоящее время я обновляю древний IVR, написанный с использованием Classic ASP, с VXML 2.0. Поверьте мне, это был беспорядок, в основном из-за смешивания логики маршрутизации между кодом ASP и логикой VXML, включающей несколько обратных передач в стиле ASP.NET. Не весело отлаживать.

Итак, мы начинаем с MVC 3 и Razor, и пока все хорошо. Мне удалось перенести почти всю логику обработки на контроллер и просто позволить большей части VXML просто озвучивать приглашение и ждать ответа DTMF.

Но, глядя на множество примеров кода VXML, начинает казаться, что на самом деле может быть проще выполнить базовую маршрутизацию с использованием нескольких страниц и встроенной обработки DTMF и VXML. Более сложный процесс принятия решений и доступа к базе данных / серверу вызовет контроллер, как сейчас.

Я разрываюсь между желанием быть строгим в том, где находится логика, и тем, что на самом деле может быть более простым кодом. Мой VXML не очень продвинутый (я знаю достаточно, чтобы быть опасным), поэтому я собираю информацию. Другие использовали несколько форм на странице? Лучше или хуже?

Спасибо

Джим Стэнли Blackboard Connect Inc.

Answer 1

Наша текущая структура в настоящее время использует сочетание сервера и клиента. Вся наша логика в VoiceXML, а сервер используется для сохранения состояния и генерации компонентов распознавания. К сожалению, поскольку вся наша логика в voicexml, это затрудняет юнит-тестирование.

Вместо того, чтобы создавать большую страницу voicexml, которая поддиалогирует к каждому вопросу, и всю маршрутизацию, выполняемую на стороне клиента, отправляйте обратно на сервер после каждой коллекции, а затем решайте, куда идти. Очевидно, в этом есть свои плюсы и минусы, как указал Джим, но надежда состоит в том, чтобы абстрагировать часть IVR / callflow от VoiceXML и уменьшить зависимость от повышения квалификации разработчиков в VoiceXML.

Я смотрю на повторную разработку с использованием MVC3, создание различных представлений на основе базовых функций IVR, которые затем можно изменить на основе платформы VoiceXML для хостинга:

• Признание
• Запрашивает
• Перевод
• CTI Get / Set
• Disconnect

Я до сих пор работаю над тем, как создавать повторно используемые компоненты в MVC. Нужно ли создать что-то, для чего мы выполняем субдиалог, и вернуть результат (аналогично тому, как мы это делаем в настоящее время), или перенаправить на универсальный контроллер, а затем перенаправить на действие «Завершено» после завершения работы контроллера.

Answer 2

Выбор простого VoiceXML и перемещение на стороне логического сервера - довольно распространенная практика. Плюсы / минусы ниже.

логика на стороне сервера

• Часто трудно заставить счетчики повторов работать так, как вы хотите, если вы также выполняете проверку ввода (действительна для грамматики, но не для хоста или другой логики проверки)
• Лучше язык программирования / инструментарий для создания логических описаний (я не фанат JavaScript, но даже если вам нравится JavaScript, вам, как правило, приходится создавать множество форм, чтобы получить желаемое управление потоком).
• Обычно легче отлаживать. Шаг через логические решения и доступ к инструментам ведения журналов.
• Обычно проще создавать повторно используемые компоненты, которые используют параметры для изменения поведения компонентов.

Клиентская логика

• Обычно более масштабируемый. Браузеры VoiceXML часто используют свои ресурсы для компиляции и обработки страниц. Одна большая страница обычно работает лучше, чем множество маленьких страниц. Тем не менее, платформы значительно различаются, и ваш размер может сделать это незначительным.
• Лучший шанс использования статических страниц. Многие платформы имеют высоко оптимизированные кеши (больше, чем просто извлеченные данные). Подобное выше может иметь значение, только если у вас есть 100 портов на устройство или 1000 портов, попадающих на сервер.

Смешивание и сопоставление неплохо, пока кто-то не запросит какое-то глобальное изменение поведения. Вы можете вносить изменения в нескольких местах. Методы отладки также могут различаться, поэтому это может усложнить ваши пути поддержки (например, просмотр журналов браузера по сравнению с журналами сервера, чтобы увидеть, что произошло при вызове).

Answer 3

Джим Раш (Jim Rush) дает довольно хороший обзор плюсов и минусов серверной и клиентской логики и вполне соответствует моей дискуссии по этой теме в моем блоге: « Разработка на стороне клиента VoiceXML на стороне сервера».Приложения ».Я считаю, что плюсы размещения логики на сервере намного перевешивают его на клиенте.Группа пользователей VoiceXML движется в направлении удаления большей части этой логики из VoiceXML в версии 3.0 и предлагает использовать новый стандарт, называемый State Chart XML (SCXML), для управления голосовым приложением.Я начал проект с открытым исходным кодом, чтобы упростить разработку приложений VoiceXML с использованием ASP.NET MVC 3.0, который можно найти в CodePlex и называется VoiceModel .В этом проекте приведен пример приложения, в котором будет продемонстрирован метод сохранения стороны логического сервера, который, как мне кажется, значительно улучшает повторное использование голосовых объектов.