Вам придется учесть разницу между Лексом и Алекса. Наиболее заметными различиями являются форматы запросов и ответов.
sessionAttribtues
и slots
. slotTypes
, которые Alexa не использует (пока?): AMAZON.EmailAddress,
, AMAZON.Percentage
, AMAZON.PhoneNumber
, AMAZON.SpeedUnit
и AMAZON.WeightUnit
. ( Ссылка. ) inputTranscript
. Алекса нет. resolutions
для значений слотов, но заполняет фактическое значение слотов необработанными данными, извлеченными из ввода. slotType
. После работы с ними обоими довольно часто, и часто имея дело с этим, я предпочитаю Лекса, а не Алекса. Я обнаружил, что Lex проще и обеспечивает больше свободы для разработчика и контроля, даже если вы должны соответствовать ограничениям каждого из выходных каналов Lex.
Формат Alexa JSON
Формат Lex JSON [1131 ]
{
"version": "1.0",
"session": {
"new": true,
"sessionId": "amzn1.echo-api.session.[unique-value-here]",
"application": {
"applicationId": "amzn1.ask.skill.[unique-value-here]"
},
"attributes": {
"key": "string value"
},
"user": {
"userId": "amzn1.ask.account.[unique-value-here]",
"accessToken": "Atza|AAAAAAAA...",
"permissions": {
"consentToken": "ZZZZZZZ..."
}
}
},
"context": {
"System": {
"device": {
"deviceId": "string",
"supportedInterfaces": {
"AudioPlayer": {}
}
},
"application": {
"applicationId": "amzn1.ask.skill.[unique-value-here]"
},
"user": {
"userId": "amzn1.ask.account.[unique-value-here]",
"accessToken": "Atza|AAAAAAAA...",
"permissions": {
"consentToken": "ZZZZZZZ..."
}
},
"apiEndpoint": "https://api.amazonalexa.com",
"apiAccessToken": "AxThk..."
},
"AudioPlayer": {
"playerActivity": "PLAYING",
"token": "audioplayer-token",
"offsetInMilliseconds": 0
}
},
"request": {}
}
{
"currentIntent": {
"name": "intent-name",
"slots": {
"slot name": "value",
"slot name": "value"
},
"slotDetails": {
"slot name": {
"resolutions" : [
{ "value": "resolved value" },
{ "value": "resolved value" }
],
"originalValue": "original text"
},
"slot name": {
"resolutions" : [
{ "value": "resolved value" },
{ "value": "resolved value" }
],
"originalValue": "original text"
}
},
"confirmationStatus": "None, Confirmed, or Denied (intent confirmation, if configured)"
},
"bot": {
"name": "bot name",
"alias": "bot alias",
"version": "bot version"
},
"userId": "User ID specified in the POST request to Amazon Lex.",
"inputTranscript": "Text used to process the request",
"invocationSource": "FulfillmentCodeHook or DialogCodeHook",
"outputDialogMode": "Text or Voice, based on ContentType request header in runtime API request",
"messageVersion": "1.0",
"sessionAttributes": {
"key": "value",
"key": "value"
},
"requestAttributes": {
"key": "value",
"key": "value"
}
}
Я всегда позволяю подобным вещам быть довольно подвижными. При этом:
Я склонен делать комбинацию того, что делают Рэндольфо и Бен: я использую статические вспомогательные классы в папке «Utilities» в пространстве имен Utilities. Лучшая организация файлов, сохраняющая остальную часть пространства имен приложения чистой.
Я склонен помещать их в пространство имен утилит. Либо в пространстве имен основного проекта, если они довольно общие, например MyProject.Utils.MyHelperClass
, или, если они более конкретны, то подпространство имен MyProject.CRM.Utils.MyCRMHelperClass
.
Мы поместите такие классы в сборку с именем Common
, например, предназначенную для использования всеми проектами, которым это необходимо, за исключением случаев, когда помощнику необходимо использовать некоторые бизнес-объекты или основные объекты.
Большинство из нас просто помещает их в папку «Помощники».
В зависимости от помощника вы можете пометить методы как виртуальные, чтобы при необходимости можно было смоделировать их. Это или привязка к интерфейсу, который он реализует, но если у вас есть только один конкретный интерфейс для каждого интерфейса, это может быть излишним.
Если вспомогательные методы не являются чистым вычислением без внешних зависимостей, они ни при каких обстоятельствах не должны быть статичными.
Даже тогда пересмотрите.
У меня почти всегда есть библиотека классов MyProject.Core в моем решении, куда я помещаю такие вещи.
Edit: Я мог бы ответить на более «большой» вопрос.
В одном проекте все зависит от размера проекта. В Руководстве по дизайну Microsoft говорится о том, что вам не следует создавать пространство имен, если в нем меньше пяти (поправьте меня, если я ошибаюсь насчет этого числа) типов.