我们目前正在开发一种使用 Azure 函数和 Azure 存储队列绑定(bind)的设计。 队列中的每条消息代表一个完整的事务。 Azure 函数将绑定(bind)到该队列，以便队列中出现新消息时立即触发该函数。 然后该函数将在 SQL DB 中提交事务。
初步实现也已完成；并且运行良好。然而，回顾过去，我们正在考虑以下几点: 在典型的 DAL 中，有使用 Entity Framework 、存储库模式等的完善设计模式。但是，在无服务器代码中实现 DAL 时，我们没有找到类似的指导/最佳实践。 因此，我的问题是:此类模式是否应该使用 Azure 函数来实现(这将具有挑战性:))，或者无服务器代码是否应该尽可能保持轻量，否则这根本不是 azure 函数的用例？
最佳答案
不需要任何太特别的东西。我们使用一组常规的库 DLL 来处理各种事务 - 数据库、与 Azure 的其他部分交互(例如检索连接字符串的 Key Vault secret )、解析文件上传、业务规则等。这些库以 netstandard20 为目标，因此当正确的触发器可用时，我们可以更轻松地迁移到 Functions v2。
主要是设计您的库，使它们高度模块化，这样您就可以最大限度地减少完成工作所需的加载量(假设在系统的其他区域中重用很重要，通常也是如此)。
如果现在可以使用依赖注入(inject)的话会更容易。请参阅this在获得官方 DI 支持之前，我们中的一些人已经通过多种方式将其组合在一起。 (DI 位于 Functions 的路线图上，我相信 3.0 版本会发布。)
起初，我有点担心库方法的启动时间，但底层 WebJobs 堆栈本身已经相当重，而且 Functions 启动性能似乎无论如何都有很大差异(至少在更便宜的层上)。在测试过程中，我们不常执行的函数之一的变化范围从大约 300 毫秒到大约 3800 毫秒的峰值，以解析完全相同的测试文件，除了大约 55 毫秒外，所有函数都花费在启动上。
关于azure - 使用 azure 函数的数据访问层模式，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/48900315/