这些包代表的是各个运行时与代码交互方式的差异。，描述了如何将传入事件转换为 .Net Core 对象以供使用。在这两种情况下，传入的触发器都是 HTTP 事件。在 Azure 上，这会产生一个名为req的HttpRequest对象，而在 AWS 上，您会得到一个名为apigProxyEvent的APIGatewayProxyRequest对象。虽然这些对象不同，但它们在很多方面相似，但不足以使代码在它们之间轻松移植。因此，将相同的代码放入这些不同的运行时中是行不通的。嗯，至少要做一些额外的工作。
为了帮助我们前进，AWS Lambda 代码指明了方向。虽然 Azure 函数以文字单个函数开始，但 Lambda 代码将代码拆分为传入触发器和实际代码。这种划分是能够在平台间正确迁移的关键。当然，所涉及的平台需要运行相同版本的语言，但在撰写本文时似乎确实如此，因为 Azure 和 AWS 都特别支持 .Net Core 2.1，即使存在较新版本的 .Net Core，并且 Azure 甚至在预览中提供了较 BC 数据 新的 Functions 运行时。如果担心迁移，需要记住的一点是，坚持使用您感兴趣的语言的 LTS（长期支持）版本似乎是明智的。
划分的诀窍可以归结为基本上已经是最佳实践的方法：分离功能逻辑及其接口。接口是处理与运行时交互的部分。在这种情况下，它是APIGatewayProxyRequest和HttpRequest对象。关键是从这些对象中获取运行逻辑所需的内容（例如适当的 HTTP 标头、查询参数等，还有环境特定变量，如连接字符串），然后将该数据发送到单独的方法。一旦逻辑完成，其返回值需要由接口部分处理，以挂接到运行时的要求（此示例中分别为 AWS 和 Azure 的APIGatewayProxyResponse和IActionResult ）。这样做的话，迁移逻辑就变成了真正的复制粘贴的事情。
最后，拥有一些代码并将其放入任何旧的运行时中的想法是不正确的。下面仍然有一个特定的运行时，您必须做一些工作才能让您的代码在所述运行时工作。但是如果您注意正确分割界面和逻辑，您应该能够相对轻松地做到这一点。