我们目前正在使用Azure功能和Azure存储队列绑定进行设计。 队列中的每条消息都代表一个完整的事务。 Azure函数将绑定到该队列，以便在队列中有新消息时立即触发该函数。 然后，该函数将在SQL DB中提交事务。
第一次实施也已完成;它工作正常。但是，回顾展上，我们正在考虑以下方面： 在典型的DAL中，存在使用实体框架，存储库模式等的完善的设计模式。但是，在无服务器代码中实现DAL时，我们没有找到类似的指导/最佳实践。 因此，我的问题是：是否应该使用Azure功能实现这些模式（这将是具有挑战性的:)），或者应该尽可能保持无服务器代码，或者这不是天蓝色功能的用例， ？
答案 0 :(得分：2)
它没有太特别的东西。我们使用一组例程库DLL来处理各种事情 - 数据库，与Azure的其他部分交互（比如检索连接字符串的Key Vault机密），解析文件上传，业务规则等等。这些库的目标是netstandard20，因此当正确的触发器可用时，我们可以更轻松地迁移到Functions v2。
主要是设计您的库以使它们高度模块化，这样您就可以最大限度地减少加载工作量（假设在系统的其他区域重用很重要，通常是这样）。
如果依赖注入今天可用会更容易。请参阅this了解我们中的一些人在我们获得官方DI支持之前将其一起入侵的方法。 （DI是功能的路线图，我相信3.0版本。）
起初我对使用库方法的启动时间有点担心，但底层的WebJobs堆栈本身已经相当沉重，而且函数启动性能似乎变化很大（至少在更便宜的层上）。在测试期间，我们不常执行的函数之一从大约300毫秒变化到大约大约3800毫秒的峰值来解析完全相同的测试文件，在启动时花费了大约55毫秒。
答案 1 :(得分：0)
应该使用Azure函数实现这种模式（这将 很有挑战性:)），还是应该减少无服务器代码 可能，或者这根本不是azure函数的用例？
我的回答是“否”。 应该遵循一些模式，但是传统的存储库模式和CRUD操作在云时代似乎无效。 这些年来，我们被提出要遵守的许多重要概念变得无效。 对数据库进行非规范化不仅可以接受，而且更可取。
现在设计模式将取决于您为解决方案选择的数据库，还取决于您的应用程序类型和数据类型。
这是您进行Table Storage design Guidelines时通用准则的链接。
您的应用程序是大量读取还是大量写入？设计将相应地变化。 您正在使用Azure Tables还是Mongo？有基于此的设计决策。索引在Mongo中很重要，而Azure表中没有索引可以做。
共享考虑。 冗余考虑。
在现代开发/架构中，许多原则已经改变，每个微服务都有自己的数据库，该数据库可能与其他微服务完全不同。
如果您按照我提供的指南进行阅读，将会明白我的意思。
设计表服务解决方案以提高阅读效率：
用于读取大量应用程序中的查询的设计。在设计表时，请先考虑将要执行的查询（尤其是对延迟敏感的查询），然后再考虑如何更新实体。通常，这会产生高效且高性能的解决方案。 在查询中同时指定PartitionKey和RowKey。诸如此类的点查询是最有效的表服务查询。 考虑存储实体的重复副本。表存储很便宜，因此请考虑多次存储同一实体（使用不同的键）以实现更有效的查询。 考虑对数据进行规范化。表存储很便宜，因此请考虑对数据进行规范化。例如，存储摘要实体，以便对聚合数据的查询仅需要访问单个实体。 使用复合键值。您仅有的键是PartitionKey和RowKey。例如，使用复合键值来启用对实体的备用键控访问路径。 使用查询投影。您可以通过使用仅选择所需字段的查询来减少通过网络传输的数据量。 设计您的Table服务解决方案以提高写入效率：
不创建热分区。选择使您能够在任何时间跨多个分区散布请求的键。 避免流量高峰。在合理的时间内平滑流量，避免流量高峰。 不必为每种类型的实体创建单独的表。当您需要跨实体类型进行原子事务时，可以将这些多个实体类型存储在同一表的同一分区中。 考虑您必须达到的最大吞吐量。您必须了解Table服务的可伸缩性目标，并确保您的设计不会导致超出您的目标。
另一个link的好来源是