我正在设计和实现 .Net ORM，它必须同时支持 Azure 存储（表、队列、blob）和 AWS 存储（EBS、SimpleDB、S3），并将所有实现细节隐藏在一个通用接口后面。主要的设计目标是简单。
一些工作已经在http://www.cs.virginia.edu/~humphrey/papers/CSAL.pdf中完成，但在我看来，他们提出的接口与 Azure/AWS 存储接口耦合过于紧密，并且是如果添加新功能或更改旧功能，可能会中断。例如，我不在乎我可以创建/删除表，我只需要以最有效的方式存储某种类型的对象。
所以，我想请你以指导的形式分享你在这个主题上的经验（做、考虑、避免、不要）。我真的很感激任何从设计 ORM 的一般原则开始并以精确的抽象级别结束的见解，考虑到 Azure 和 AWS 最可能的进化路径，这种抽象级别更有可能持续下去。
如果您真的想避免紧密耦合，我建议您在两种存储类型上可用的最小功能集之上简单地实现和抽象层。
但无论如何，你试图做的事情对我来说真的没有意义。云（非关系）存储是如此奇特，以至于试图构建一个通用的 ORM 将是一个巨大的失败。现代 SQL ORM 是“好”的，因为 RDBMS 都具有共享的最小功能集，这些功能实际上非常庞大，并且在大多数情况下您不需要异国情调的东西。使用云存储，每个实现几乎都是独一无二的，正是因为要牢记的第一个方面是可扩展性。例如，如果您在 Azure 中丢弃 Blob 租约，因为它们在 Amazon 中不存在（我不知道，我只是在做一个示例），那么您可能很难在 Amazon 中管理 Blob 并发访问，并且在 Azure 中也是如此，这没有任何意义。
我宁愿尝试实现一个设计合理的数据访问层，以避免出现问题，但利用两个平台中的所有可用功能（如果有必要，实现非常不同）。