使用 Azure Functions 构建机器人部署

Question

我一直在使用机器人框架，并使用基于 Azure Functions 的 LUIS 引擎创建了一个新机器人。我目前的主要代码在 CSX 文件中，但我很快就遇到了不合适的地方。

因此，我试图找到一些关于如何以最佳方式构建此类项目的最佳实践。目前我看到以下三点我认为需要分开：

1. 链接到 LUIS 意图的代码。这应该很简单，并且只包含从意图和实体中获取正确参数的代码。
2. 验证逻辑和东西。例如：我的用户输入了一个时间段，我想检查输入的时间段是否有效（例如开始日期在结束日期之前）。
3. 意图通常应该做某事，所以我们需要有代码来触发这个动作。步骤 1 和 2 的结果用于确定需要做什么以及使用哪些参数。将其抽象为另一个函数（每个操作）似乎是有意义的？？

我正在寻找的是一些关于如何设置 a) 有效且 b) 可用的架构的真实世界经验。关于可用，我的意思是：当然可以为每一件小事创建微服务，但如何处理维护、源代码控制、更新和所有这些东西。我非常了解可能没有一个正确的答案，但是指向正确方向的东西对开始会很有帮助。

Answer 1

这是一个相当广泛的问题。我会尽量覆盖。所以首先我强烈建议你通过C# documentation。 CSX 和您的 CS 类之间应该没有根本区别。如果感觉太难了，或者您需要 IDE 体验，您始终可以使用您将拥有的所有逻辑创建一个 Visual Studio 项目；然后在链接类的函数中使用已编译的二进制程序集。

• 对于您的 LUIS 问题，已经有 LUISDialog 类。它负责调用 LUIS、识别实体、意图等。您只需实现属性良好的方法。查看示例here。
• 对于验证和输入，我建议您查看FormFlow。它有很多你要求的东西，包括验证。
• 如果您对显式流程管理感兴趣，您希望从一个步骤获取结果并将其链接到下一步。 SDK 已经有Dialog Chains。

我认为框架本身为您提供了基本的构建块，然后像任何好的框架一样让您去想象。组织代码的方式过于主观。我的观点可能与您可能拥有的不匹配，并且这里没有像 MVC 或 MVVM 这样的固定模式。我通常会尝试将我的代码组织成两部分。

• 业务逻辑层。从调用您的数据库到您的验证，再到支付网关等，一切都在这里。这部分应该是可测试的，任何人都可以通过类和接口重用。您可以在此处应用各种架构/设计模式。想法是这一层是您应用的实用接口。
• 通信层。这将专门处理 Dialogs、FormFlows、Intents 等，并规范化要调用到您的业务逻辑中的数据。这部分将主要处理处理用户输入，并处理所有交互逻辑。

现在，如果项目非常庞大，我可能会从这些层构建 nugets，并将其作为导入的包重用在 CSX 中。在这种情况下，CSX 部分真的很像路由器，它通过仿真器和测试用例为您提供可调试性、本地可测试性，并且只需将更改推送到 packages.json 即可由 CI 轻松部署。