我正在开发一个c# web应用程序，它将托管在Windows Azure上，并使用表数据存储(TDS)。
我想构建我的应用程序，这样我也可以(作为一个选项)将应用程序部署到具有其他NoSql后端的传统IIS服务器上。基本上，我想给我的客户一个选择，要么以软件即服务模式向我付费，要么购买我的应用程序的许可证，他们可以将其安装在自己的(非azure)生产服务器上。
我怎样才能最好地构建我的数据层和中间层来实现这两个目标?
我可能需要一个Windows Azure Worker Role和一个Azure Queue。复制这些有多复杂?我可以替换自定义Windows服务和其他排队技术吗?
如何编写数据模型中的实体，以便在不部署到Azure时可以部署到Azure TDS或其他一些存储?MongoDB或类似的是有用的吗?
当然有一种方法可以在不与Azure结婚的情况下构建Azure。
我可能需要一个Windows Azure Worker Role和一个Azure Queue。复制这些有多复杂?我可以替换自定义Windows服务和其他排队技术吗?
是的，一个带有其他排队技术的Windows服务会很好地适应这种情况，并且worker角色有一个main/Run循环，这在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结婚的情况下构建Azure。
是的，正如你在问题中建议的那样，你可以设计你的应用程序，这样它就可以在其他技术上工作。实际上，这与传统的SQL数据抽象方法面临的挑战非常相似。然而，我认为有一些地方你会发现TDS一定会推动你不适合其他存储的方向——例如Azure将你推向数据复制;对钥匙有非常具体的规则;使用非常特定的机制提供高性能;并且在非常特定的情况下提供有限的事务完整性。这些因素可能意味着你确实需要改变一些中间层和一些数据层，以便在Azure和非Azure版本中充分利用你的应用程序。
另一种想法-在Azure上为客户提供多租户SaaS版本，在Azure上提供单租户版本可能更容易-但这确实取决于客户端!
我找到了一个可行的解决方案。我发现，如果我用相同的PartitionKey设计我的实体，我可以使用EF Code首先与SQL Server或SQL CE。Azure表存储需要的RowKey复合键结构。
在Lokad Cloud (http://code.google.com/p/lokad-cloud/)的一点点帮助下执行与Azure表存储的交互，我能够制作一个通用的DataContext，它提供了对EF的DbContext或Lokad的TableStorageProvider的crud操作。
我甚至找到了一个很好的方法来管理实体之间的关系，并适当地延迟加载它们。
解决方案有点复杂，需要更多的测试。我会在博客上写下来，准备好了就把链接贴在这里。