将表中的数据映射到枚举的 XSD 或 CLR 对象
我目前正在使用标准 4.0 Web 表单应用程序（无动态数据），并且我想尝试使我的站点配置尽可能动态。
我有一个数据库表，其中每一行代表一种文件类型。我想要创建一个流程，其中站点配置足够动态，可以根据对此表的更改来处理和吸收对其配置的更改。
目前，我的 web.config 文件的 configsection 中有一组条目，它代表文件类型的集合。因此，如果我想处理 PDF 文件，也许我会在文件类型部分添加类似
每个键在我的数据库中都有一个条目，并且我使用枚举将友好名称/CLR 对象映射到数据库值（整数）。我喜欢这样在标签属性中轻松使用它的方式，例如
问题是，这个枚举目前是硬编码的，我不知道有什么好方法可以使这个动态处理将来的添加或删除。就目前情况而言，如果我想添加新的文件类型，我必须向数据库添加一个新行，在 web.config 中为其添加一个条目，然后使用新 ID 更新枚举。这对我来说没问题，但这有点手动，而且我也不能说我们的支持人员有能力遵循该程序。
我认为从概念上对我来说造成障碍的事实是，我实际上是在尝试将模式对象的实例组合转换为一种类型，而不是将 DB 模式转换为 CLR 模式。
我正在使用实体框架，因此利用其中的某些东西不是问题。
我正在考虑使用 xsd.exe，但由于我不热衷于安排它运行或调用它来刷新架构，因此让其他开发人员经历该过程可能比仅手动更新枚举更麻烦。然而，如果我能在这条路线上做点什么，我非常愿意去看看。
澄清一下，我并不是真的热衷于在 web.config 中使用它，这只是我如何让它以硬编码的方式很好地工作。
理想情况下，我想要做的是自动神奇地解析和/或识别源自数据库的数据，其中我可以将其名称或简单英语表示形式放在标签属性中。我认为这很可能看起来像客户端引用的某个 xml 模式文件。
如果您有任何建议，我将非常感激。谢谢你们。
I'm currently using a standard 4.0 Web Forms app (no dynamic data) and I'd like to try to make my site configuration as dynamic as possible.
I have a database table where each row represents a file type. I want to make a process where the site configuration is dynamic enough to handle and assimilate changes to its configuration based on changes to this table.
Currently I have a collection of entries in a configsection in my web.config file which represents a collection of file types. So maybe I'd have something like <add key="Pdf"> in a filetypes section if I want to be working with PDF files.
Each of these keys has an entry in my database, and I'm using an enum to map a friendly name/CLR object to the database value (integer). I like the way that I can then use this easily in a tag attribute e.g. <cc1:MyControl FileType="Pdf">, and I can use a combination of database data and additional attributes from web.config to allow Intellisense to really do its thing.
Problem is, this enum is hard-coded currently and I don't know a good way to make this dynamic to handle future additions or deletions. As it stands, if I want to add a new file type I'd have to add a new row to the database, add an entry for it in the web.config, and then update the enum with the new ID. That's okay for me, but it's a bit manual and also I can't speak for the ability of our support to follow that procedure.
I think what is causing a roadblock conceptually for me is the fact that instead of translating DB schema to CLR schema, I'm actually trying to convert a conglomeration of instances of a schema object to one type.
I am using entity framework so leveraging something in there is not a problem.
I was considering using xsd.exe, but as I'm not keen on scheduling it to run or calling it to refresh the schema, having fellow devs go through that process is probably more unwieldy than just updating the enum manually. However if there's something I can do that route I am more than willing to check it out.
To clarify, I'm not really hung up on having this in web.config, this is just how I did it to get it to work nice and pretty-like in a hardcoded fashion.
Ideally, what I'd like to do is to have data that originates from the database auto-magically parsed and/or recognized, where I can just put its name or representation in plain English in a tag property. I'm thinking this is most likely going to look like some xml schema file that the client references.
If you have any suggestion, I'd really appreciate it. Thanks guys.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我最终放弃了 web.config。我本可以自己进行转换，但我决定使用 T4 模板。我将存储在 web.config 中的数据移动到数据库中的字段中，然后使用 T4 模板来查询数据库并获取所有行并为它们生成枚举值。然后我创建了隐式运算符来将枚举类型转换为实体，反之亦然，例如
get{ return context.Where(myVar => myVar.myKey == (int) myEnumVal);所以现在我的支持人员不必破解代码，他们只需在数据库中添加一行，设计时模板就会生成新值。
I ended up moving away from web.config. I could have made my own transform, but I decided to use a T4 template instead. I moved the data that was stored in web.config into fields in the database, then I used a T4 template to query the DB and get all of the rows and generate enumerated values for them. Then I created implicit operators to convert the enumerated type to an entity and vice versa, e.g.
get{ return context.Where(myVar => myVar.myKey == (int) myEnumVal);So now my support doesn't have to crack open the code, they just add a line in the database, and the design-time template will generate the new value(s).