Web services 数据库驱动的服务配置-设计或过度设计

问这个问题时非常紧张，但想把这个问题说出来，并得到一些关于为什么/为什么不/为什么会有人想这么做的反馈。 我有各种web服务/窗口服务，它们具有各种配置值，这些配置值通常存储在各自的配置文件中

我认为有一个中央服务是有意义的，它的唯一目的是提供相应的web/window服务它需要的所有配置细节。配置将存储在数据库表中，每个服务将通过单个web服务请求各自的配置

我的问题是，这听起来像是过度设计，还是有其他想法可以达到几乎相同的效果。我觉得这将集中配置，因此更易于管理。此外，所有服务都必须符合配置接口，该接口将具有已定义的配置/值对NameValueCollection属性

如有任何反馈，将不胜感激

---

如果访问配置服务所需的信息本身就在配置中，那么Web服务[ABC]如何获得其配置？除非您有一组快速变化的大量配置值，对我来说，这似乎是一个过度设计的解决方案。他们各自的配置文件只包含配置服务参考，而不包含其他配置值。这是一种架构风格的选择，没有对错，只有成功和不成功的选择。正如Jonathon Reinhart所提到的，除非你的配置改变了很多，否则你可能是设计过度了。另一方面，如果您确实遇到了这个问题，那么解决方案可能会起作用。请记住，拥有一个存储配置的数据库意味着您可能必须将该DB服务器放入一个高可用性解决方案中。这是额外的事情，可能会出错，需要更多的努力和维护。感谢您的反馈。这没有问题，您仍然需要一些东西来引导服务A、B和C，以告诉他们配置服务在哪里，以及可能如何与之交互。我发现这样做的一个好处是，您现在有一个地方可以查看您的服务应该如何运行，并且可以通过查看数据库或配置服务更轻松地审核您的服务配置。