您在数据应用程序中使用枚举吗？如何使用？
我的实践表明，一般的企业应用程序有很多实体，其性质对应于基本枚举。例如，我们可能有一个订单实体，它可能具有“OrderType”、“OrderStatus”、“Currency”等字段，引用相应的实体，这些实体只不过是绑定到要引用的键的文本名称。
在这里使用枚举看起来很自然。但是实体必须在设计时在应用程序代码中定义，对吗？而我们需要能够在运行时 CRUD 枚举值变体，并在服务器端 SQL 查询（如存储过程和视图）中使用枚举。
您对此主题有哪些实践和想法？
我对 C#4、linq 和 T-SQL 特别感兴趣。
My practice shows that a general enterprise application has a lot of entities which's nature corresponds to an elementary enumeration. For example We may have an Order entity which may have such fields as "OrderType", "OrderStatus", "Currency", etc. referencing corresponding Entities which are nothing more than just a textual name bound to a key to be referenced.
Using enums would look very natural here. But entities have to be defined in application code at design-time, am I right? While in we need to be able to CRUD enum value variants at runtime and use enums in server-side SQL queries (like stored procedures and views).
What are you practices and thoughts on this subject?
I am particularly interested in C#4, linq and T-SQL.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我使用枚举来表示数据库值，这些值永远不应该由用户创建或更改，并且如果存在基于该值的特殊逻辑。货币不是一个很好的例子，除非您枚举了每种货币，并且接受如果出现新货币或已弃用一种货币，则必须重新编译应用程序。如果您的系统中有基于 OrderStatus 的逻辑，OrderStatus 可能是一个很好的示例。无论如何，应该注意的是，如果您确实创建了一个枚举来表示数据库值，则如果需要在此表中创建新值，则必须重新编译应用程序，因此应非常谨慎地使用此做法。
在我要使用枚举模拟数据库值的情况下，我使用枚举值的名称作为表的主键以及传递给外键的值。即，当我保存到数据库时，我将传递
myEnumVal.ToString()。我这样做有几个原因。首先，它要求增加价值更加刻意。如果我使用数值作为主键，则暗示我正在使用代理键并且可以轻松添加其他值。当其他开发人员看到使用名称作为主键的列时，他们更有可能认为该值不是任意的。其次，它使数据库代码更容易阅读。您会收到类似Where OrderStatus = 'Active'的查询，而不是Where OrderStatus = 1。I use enums for database values that should never be created or altered by a user and if there is special logic based on the value. Currencies are not a good example unless you have every currency in your enumeration and accept that you will have to recompile your app should a new currency come along or one is deprecated. OrderStatus might be a good example if you have logic in your system based on the OrderStatus. Regardless, it should be noted that if you do create an enumeration to represent a database value, that the application must be recompiled should a new value in this table need to be created and thus this practice should be used with great caution.
In situations where I'm going to mimic a database value with an enumeration, I use the name of the enumerated value as the primary key of the table and as value passed to the foreign key. I.e., when I save to the database, I'm going to pass
myEnumVal.ToString(). I have a couple of reasons for this. First, it requires that adding a value is more deliberate. If I were to use the numeric value as the primary key, there is an implication that I'm using a surrogate key and that additional values can easily be added. When other developers see a column using a name as the primary key, there is a higher chance that they'll think that the value is not arbitrary. Second, it makes database code significantly easier to read. You get queries likeWhere OrderStatus = 'Active'instead ofWhere OrderStatus = 1.从某种意义上说，C# 枚举类似于面向对象的类层次结构。如果您使用替代项
One和Two声明枚举Choice，则有点类似于使用基类Choice< 声明类层次结构/code> 和两个派生类型（One : Choice和Two : Choice）。一个区别是枚举不可扩展（如果需要添加案例，则需要修改声明，而如果需要向类层次结构添加案例，则只需定义一个新的继承类型即可）。< /p>
第二个区别是枚举的选项不能携带额外的数据 - 如果您声明类层次结构，则可以在
One情况下存储其他字段（例如）。如果没有这两个“限制”，您可以考虑使用枚举来表示应用程序中的实体（事实上，函数式语言具有类似于这些“更强大”枚举的构造，并将其用于此类事情）。
但是，由于 C# 枚举非常简单，因此它们主要用于表示与特定域无关的值，或者在编程中更普遍需要的值。例如：
这可能是非常有用的类型，但它与任何特定域不直接相关。
In some sense, C# enums are similar to a object-oriented class hierarchy. If you declare enumeration
Choicewith alternativesOneandTwo, it is a bit similar to declaring a class hierarchy with base classChoiceand two derived types (One : ChoiceandTwo : Choice).One difference is that enumerations are not extensible (if you need to add a case, you need to modify the declaration, while if you need to add a case to a class hierarchy, you simply define a new inherited type).
Second difference is that options of an enumeration cannot carry additional data - if you're declaring class hierarchy, you can store other fields in the
Onecase (for example).Without these two "limiations", you could consider using enumerations to represent entities in an application (in fact, functional languages have construct similar to these "more powerful" enumeration and use it for these kind of things).
However, since C# enumerations are very simple, they are mostly used to represent values independent of the specific domain, or values that are needed more generally in programming. For example:
This could be quite useful type, but it isn't directly related to any specific domain.