2016-12-29 146 views
0

我一直在玩bot框架,并使用基于Azure函数的LUIS引擎创建了一个新的bot。我目前的主要代码是在CSX文件中,但我很快就跑到了不觉得这是正确的事情。使用Azure函数构建bot部署

所以我试图找到一些关于如何最好地构造这些类型的项目的最佳实践。目前我看到以下三件事在我看来需要分开:

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

我在找的是一些关于如何设置a)工作和b)可用的体系结构的实际经验。可用的我的意思是:当然可以为每个小东西创建微服务,但是如何处理维护,源代码控制,更新以及所有这些东西。我非常明白,可能没有一个正确的答案,但是指向正确方向的东西对于开始将会非常有帮助。

回答

1

这是一个相当广泛的问题。我会尽可能地尽力掩护。所以首先我会强烈建议你通过C# documentation。 CSX和你的CS类应该基本没有区别。如果事情感觉太困难或者您需要IDE体验,您可以随时创建一个Visual Studio项目,其中包含您将拥有的所有逻辑;然后在链接类的函数中使用编译后的二进制程序集。

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

我认为框架本身为您提供了基本构建模块,然后将它留给您的想象,就像任何良好的框架应该。组织代码的方式过于主观。我的意见可能与您可能不符,并且在这里没有像MVC或MVVM这样的固定模式。我通常会尝试将我的代码分成两部分。

  • 业务逻辑层。从拨打电话到您的数据库,到您的验证,到支付网关等等的一切。去这里住在这里。这部分应该是可测试的,任何人都可以通过类和接口重用。您可以在这里应用各种体系结构/设计模式。想法是这个层是你的应用程序的实用接口。
  • 通信层。这将专门处理对话框,FormFlows,Intents等。并将要调用的数据标准化为业务逻辑。这部分主要处理用户输入,并处理所有的交互逻辑。

现在真正的大项目的情况下,我可能会建立nugets这些层和重复使用它作为您的CSX导入的包。在这种情况下,CSX部分真的很像路由器,它可以通过模拟器和测试工具为您提供可调试性和本地可测试性,并且只需将更改推送到packages.json即可轻松部署。

+0

理解并同意。对于我认为的构建块,我有一个很好的想法。虽然我同意你关于框架的声明,而不强制任何结构或体系结构,但如何建立一个系统而不会像其他人已经犯过的错误一样有最佳实践是很好的。但是,感谢这个信息,非常有用! – Jasper