在哪里存储可以由用户更新并在列表中显示给用户的值对象？
我正在尝试了解将在 Web 应用程序的下拉控件中显示的项目，这些项目是我的模型中的值对象。作为示例，我们假设有一个名为 RFI（信息请求）的实体。该 RFI 有一个名为 State 的值对象。业务规定的可能状态值有：创建、打开、暂停、关闭。这些值需要向用户显示并且可由用户更新（在某些管理控制台中）。由于这些值仅保留在实体本身上，因此存储可能值列表的最佳方法是什么？
我正在使用数据库 (SQL 2008) 和 ORM 框架 (Entity Framework 4.1)，但是我不确定数据库是存储可能值的最佳位置。我听说一些用户为此创建资源文件（XML 文档、CSV 文件等）。社区中的其他人在这种情况下正在做什么以及推荐的最佳实践是什么。
I am trying to wrap my head around items that will be displayed in a drop down control of a web application and these items are value objects in my model. As an example, let’s assume I an entity named RFI (request for Information). That RFI has a value object named State. The possible state values as prescribed by the business are: Created, Open, Suspended, Closed. These values need to be displayed to the user and are updatable by the user (In some admin console). Since the values are only persisted on the entity, itself, what is the best method to store the list of possible values?
I am using a database (SQL 2008) and an ORM framework (Entity Framework 4.1), however I am not sure the database is the best place to store the possible values. I have heard of some users creating resource files (XML documents, CSV files, etc) for such things. What are others in the community doing in a scenario like this and what are some recommended best practices.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
数据库中名为“State”（或类似）的查找表，有 4 行。
这将是“RFI”表中的外键。
原因：
例如，使用对象角色建模捕获模型并查看生成的内容。
A lookup table in the database called "State" (or similar) with 4 rows.
This will be a foreign key in the "RFI" table.
Reasons:
Capture the model with Object Role Modelling for example and see what that produces.
在我的公司中，我们在数据库中创建了一个查找表，其中有一个附加列指定每个值相关的对象，并使用不同的对象键多次映射该表（我们已经在 NHibernate 中实现了它，我不确定在 EF 中是可能的，如果不是，您可以简单地使用视图来代替）到不同的对象类。
这将允许轻松管理，因为它全部存储在数据库中，并且维护成本低，因为所有值对象仅存储在一个数据库中（这使得缓存更容易）。
In my company we created a Lookup table in the database with an additional column that specifies the object each value is related to, and mapped the table multiple times with different object-key (We've implemented it in NHibernate and I'm not sure it is possible in EF, if not you could simply use Views instead) to different object-classes.
This will allow easy management as it is all stored in the db, with low maintenance as all the value-objects are stored in only one database (which makes it easier to cache).