Azure 服务配置对其他人来说是否显得落后？
我本周刚刚迁移并部署了我的第一个 Azure Web 角色，现在部署它的压力已经消失，我正在阅读“Azure 的实际应用”，在阅读了有关配置设置的内容后，整个事情让我感到不舒服。
这对于迁移 AppSettings 类型配置设置似乎很好。但是，system.web、system.webServer 和 system.webService 或其他更复杂的配置系统中的设置又如何呢？如果我希望能够修改我的 WCF 配置设置，我当前的选项是：
- 进行更改并进行完整部署（构建、上传到暂存、切换 VIP）
- 通过自定义行为或其他方式扩展 WCF 以使用服务配置 (cscfg) ） 反而。
我想也许我误解了用法 - 就像这些例子只是非常幼稚的情况，并且在实践中它们的使用方式不同。然而，在谷歌搜索一段时间后，似乎每个人都是这样做的。例如，我必须编写自定义连接工厂。
这不仅看起来工作量太大，而且还将我的整个配置实现与 Azure 联系起来。是的，我可以使用接口，这样我就可以抽象细节并在需要时替换实现。但我仍然不喜欢所有额外的工作，connectionStrings 很简单，但还有更复杂的事情需要重写。
我的想法是，我应该能够做的是在启动时读取服务配置并使用 ConfigurationManager 来更新我的 web.config。如果运行时发生变化，我可以更新 web.config。这样我的应用程序仍然是可移植的，并且我没有硬连线到 Azure 配置系统。
有人同意吗？还是只有我这样？
I've just migrated and deployed my first Azure Web Role this week and now that the pressure is off to get it deployed I'm reading "Azure in Action" and after reading about configuration settings the whole thing rubs me the wrong way.
This seems fine for migrating AppSettings type configuration settings. However, what about settings in system.web, system.webServer and system.webService or other more complex configuration systems. If I want to be able to modify my WCF configuration settings my current options are:
- Make the change and do a full deploy (build, upload to staging, switch VIP)
- Extend WCF thru a custom behavior or whatnot to use the Service Config (cscfg) instead.
I thought maybe I was misunderstanding the use - like the examples were simply the very naive case and that in practice they were used differently. However, after googling for a while it seems that this is exactly how everyone is doing it. For example, instead of using the connectionStrings configuration element for Entity Framework connections I have to write a custom connection factory.
This not only seems like too much work, but it ties my entire configuration implementation to Azure. Yes, I can use an interface so I can abstract the details and replace the implementation if I need to. But I still don't like all the extra work, connectionStrings are simple, but there are much more complex things to override.
What I'm thinking is that I should be able to do is read the Service Configuration at startup and use the ConfigurationManager to update my web.config. If something changes at runtime then again, I can update web.config. This way my application is still portable and I'm not hardwired to the Azure configuration system.
Does anyone agree? Or is it just me?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
在这种情况下，如果 Azure 重新启动你的角色会发生什么？配置将恢复为服务配置中的配置。如果您正在运行多个实例，它们之间的配置可能会有所不同，从而产生潜在的危险结果。
一个选项是构建（一次）一个客户配置提供程序，该配置提供程序从其他地方（例如表存储）而不是 web.config 或 .cscfg 获取设置。
通过在接口后面抽象配置提供程序，您可以利用依赖注入来提供适合您的部署模型的配置机制。
我感受到你的痛苦，但这确实只是一个需要解决一次的问题。
In that case, what would happen if Azure restarted your role? The configuration would revert to that in the Service Configuration. If you're running multiple instances, configuration can then differ between them with potentially dangerous results.
An option is to build (once) a customer configuration provider that picked up settings from somewhere else (such as Table Storage) rather than web.config or .cscfg
With your configuration provider abstracted behind an interface, you can exploit Dependency Injection to provide the appropriate configuration mechanism for your deployment model.
I feel your pain, but it's really only a problem that needs solving once.
对于一个应用程序来说，要正确利用 Azure，您最终所绑定的将不仅仅是配置实现！
例如，表存储比 SQL Azure 快得多，即使使用 SQL Azure，在聚集索引的要求等方面也存在差异。
值得记住的是，与虚拟主机不同，Azure 并不是 Windows Server 的抽象：它本身就是一个平台，有自己的优点和缺点。
就配置设置而言，我认为在生产环境中相对难以更改它们是完全合理的。然而，在开发和测试时，情况显然是不同的。为此，有 Azure Web 部署，它可以让你在几分钟内完成“一次性”部署。
For an application to properly take advantage of Azure you'll end up tying much more than just configuration implementation!
For example, table storage is much much faster than SQL Azure, and even with SQL Azure there are differences regarding e.g. the requirement for clustered indexes.
It's worth remembering that unlike virtual hosts, Azure is not an abstraction of Windows Server: it is a platform in its own right, with its strengths and weaknesses.
In the case of configuration settings it's in my view entirely reasonable for them to be relatively hard to change on production boxes. It's obviously a different matter when developing and testing, however; and to that end there's Azure Web Deploy, which lets you do a "disposable" deployment in a few moments.