我正在开发将托管在 Windows Azure 中并使用表数据存储 (TDS) 的 ac# Web 应用程序。
我想构建我的应用程序，以便我还可以（作为一个选项）将应用程序部署到具有其他 NoSql 后端的传统 IIS 服务器。基本上，我想让我的客户选择以软件即服务模式向我付款，或者购买我的应用程序许可证，他们可以将其安装在他们自己的（非天蓝色）生产服务器上。
我怎样才能最好地构建我的数据层和中间层来实现这两个目标？
我可能需要一个 Windows Azure Worker Role 和一个 Azure Queue。复制这些有多复杂？我可以替换自定义 Windows 服务和其他一些排队技术吗？
如何编写数据模型中的实体，以便在不部署到 Azure 时可以部署到 Azure TDS 或其他一些存储？MongoDB或类似的对此有用吗？
当然，有一种方法可以为 Azure 进行架构设计，而无需与之结婚。
我可能需要一个 Windows Azure Worker Role 和一个 Azure Queue。复制这些有多复杂？我可以替换自定义 Windows 服务和其他一些排队技术吗？
是的 - 具有其他一些排队技术的 Windows 服务可以很好地适应这一点 - 并且工作角色具有易于在 Windows 服务中使用的主/运行循环。
如何编写数据模型中的实体，以便在不部署到 Azure 时可以部署到 Azure TDS 或其他一些存储？MongoDB或类似的对此有用吗？
NoSql 是一个概括了许多不同技术的通用术语。我认为 Azure TDS 目前属于 NoSql 的键值存储系列，而 MongoDB 更像是一个文档数据库，提供比 TDS 更丰富的功能 - 请参阅http://en.wikipedia.org/wiki/NoSQL_(concept )。对于模仿 Azure TDS，我认为 Redis 之类的变体可能会起作用（尽管我相信 Redis 本身具有比 TDS 更广泛的功能）
通常，这取决于数据的形状，但我怀疑如果您可以将其放入 Azure TDS，那么您也可以将其放入您选择的其他存储中。
当然，有一种方法可以为 Azure 进行架构设计，而无需与之结婚。
是的 - 正如您在问题中所建议的那样，您可以构建您的应用程序，以便它可以在其他技术上运行。事实上，这与传统的 SQL 数据抽象方法颇为相似。但是，我认为在某些地方，您会发现 TDS 将您推向某些与其他商店不匹配的方向 - 例如，Azure 将您更多地推向数据复制；对键有非常具体的规则；使用非常特定的机制提供高性能；并在非常特定的情况下提供有限的事务完整性。这些因素可能意味着您确实必须更改一些中间层以及一些数据层，以便在 Azure 和非 Azure 变体中充分利用您的应用程序。
另一种想法 - 在 Azure 上为您的客户提供多租户 SaaS 版本和在 Azure 上托管的单租户版本可能更容易 - 但这确实取决于客户！
我找到了一个可行的解决方案。我发现如果我使用 Azure 表存储所需的相同 PartitionKey 和 RowKey 复合键结构设计我的实体，我可以将 EF Code First 与 SQL Server 或 SQL CE 一起使用。
在 Lokad Cloud ( http://code.google.com/p/lokad-cloud /) 的帮助下执行与 Azure 表存储的交互，我能够制作一个通用的 DataContext，它提供针对 EF 的 DbContext 的 crud 操作或 Lokad 的 TableStorageProvider。
我什至找到了一种很好的方法来管理实体之间的关系并正确地延迟加载它们。
该解决方案有点复杂，需要更多测试。我将在博客上写下它，并在准备好后在此处发布链接。