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