使用 .NET 配置数据类型的反射构建动态生成的配置 UI
有没有人有任何经验/尝试这样做？
我们的 .NET 应用程序有一些相当复杂的 XML 配置，并且认为如果我们可以使用我们的配置对象层次结构来动态构建 UI，使用这些对象的属性中的反射和属性/元数据来呈现选项，那就太好了供用户生成配置。
如果能够使其变得非常通用，那就太好了，这样我们就可以为它提供任何 .NET XML 配置对象（在合理范围内），并且它会对其进行反映并允许对其进行填充。
Has anyone got any experience with / attempted to do this?
We have some reasonably complex XML config for our .NET application and were thinking it would be nice if we could use our config object hierarchy to dynamically build a UI, using reflection and attributes/meta-data from the properties on these objects to present options to user to produce the configuration.
It would be nice to make this quite generic, so we can provide it with any .NET XML config object (within reason) and it would reflect on it and allow it to be populated.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您需要准确考虑 .NET 中的配置文件的用途。它们是定义应用程序的不同部署之间差异的地方。因此，当您谈论基于编码逻辑动态更改配置时，我认为您可能理解错了。您的代码应该从通过配置注入的设置中获取指导。
您似乎正在寻找构建某种配置编辑器？当 Visual Studio 内置了两个时，为什么要这样做？编辑窗口和各种配置编辑器、ASP.NET 配置编辑器、Microsoft 服务配置编辑器等。
根据我的经验，开发环境、测试环境和生产环境中的 web 或 app.config 之间的差异通常只是一些设置，例如连接字符串、AppSettings、消息队列地址、服务端点、Log4Net 设置等。
好的，相当多的设置，但在每个配置块中，通常只有一两个属性因环境而异。 IOC 配置除外，例如 Spring.NET、CastleWinsor 或 Unity。但即便如此，不同环境下的这些通常都是完全相同的。
我鼓励你离开并思考一下这个问题。考虑一下您想要解决的实际问题。也许您需要一些数据库驱动的工作流程？我不知道。
我只知道配置不应该由运行时代码驱动。这是部署和构建时的事情。
话虽如此，有诸如 ConfigGen 之类的工具，它使得生成特定于环境的配置变得轻而易举。当这确实是您所需要的时，请检查一下。
You need to think about exactly what Config files in .NET are for. They are a place for defining the differences between different deployments of your application. So when you talk about dynamically altering config based on coded logic, I think you might have it the wrong way round. It is your code that should be taking its direction from settings injected via configuration.
It seems you are looking to build some kind of config editor? Why do this when Visual Studio has two built in? The Edit Window and the various Configuration Editors, ASP.NET configuration Editor, Microsoft Service Configuration Editor etc.
In my experience, the differences between web or app.config in a Dev environment vs a Test environment vs a production environment will typically differ by just a few settings, such as Connection strings, AppSettings, Message Queue addresses, Service Endpoints, Log4Net settings etc.
Okay, quite a few settings, but in each block of config, there is usually only one or two attributes that differ from environment to environment. The exception to this is IOC config, such as Spring.NET, CastleWinsor or Unity. But even then, these are often exactly the same from environment to environment.
I would encourage you to go away and think about this for a bit. Think about the actual problem that you are trying to solve. Perhaps you are in need of some database driven workflow? I don't know.
I just know that config should not be driven by runtime code. It is a deployment and build-time thing.
Having said that, there are tools such as ConfigGen, which makes generating environment-specific configuration a breeze. Check it out when this is really what you need.