我应该使用枚举作为鉴别器吗？答案

【问题标题】：Should I ever use Enums as discriminators?我应该使用枚举作为鉴别器吗？
【发布时间】：2025-12-12 04:15:01
【问题描述】：

枚举什么时候崩溃？

为了支持现有系统中的新功能，我只是考虑在我的数据库架构中对实体表实施某种形式的鉴别器。

为了开始做最少的事情，为了可读性，我首先决定在业务实体层使用整数列和 C# 枚举。这将提供穷人的多态性，最终可能会成长为实际的多态性，并且可能会发展为策略模式。

我决定咨询博客圈，因为我从来没有完全习惯于使用枚举 - 我想知道，我应该跳过枚举直接使用结构还是类？：

首先我发现了一个断言'Enums are Evil'，但我觉得这是一个过度概括，并没有直接解决我的用例。

如果我确实选择了一个枚举，那么有一个很好的讨论，我可以通过向我的枚举添加额外的元数据来extend my mileage。

接下来，我遇到了 Jimmy Bogard 对Enumeration Classes 的讨论，并在'Strategies and discriminators in NHibernate'中进一步讨论

我应该跳过枚举直接进入枚举类吗？或者是否有人对如何向我的域模型添加简单的实体鉴别器有任何其他建议。

更新：

我还要补充一点，NHibernate 和 LINQ to SQL（以及可能所有其他与 ORM 相关的数据访问方法）都使用枚举非常诱人，因为它们在映射中透明地let you map a discriminator column。

映射一个枚举类会那么容易吗？

相关问题：

免责声明：

尽管我粗心地使用了实体一词（带有小写“e”），但我并不想在这里讨论 DDD...

【问题讨论】：

【解决方案1】：

那些枚举类看起来很整洁，我经常嫉妒地看着 Java 的枚举。

我认为通常的规则适用：做最简单的可能工作的事情。如果您发现自己的枚举中有多个 switch，那么这是一种气味，是时候考虑您发现的模式了。

否则，为什么要用你不需要的东西来负担自己？

【讨论】：

【解决方案2】：

今天枚举是邪恶的，明天 OOP 可能是邪恶的，而 AOP 会很好。

只需为工作使用正确的工具。请记住，保持简单...

如果枚举只是为了告诉对象的类型 - 不要打扰，使用它。

如果它有一些业务逻辑，那么它可能是另一个类。

【讨论】：

从简单开始的问题是，如果我使用枚举，我的“外键”是一个整数。如果我后来将鉴别器重构为一个完整的一流实体（尽管只是一个查找表），那么我可能希望外键是一个 GUID（它恰好是我们在模式中用于键的“标准”。
然后将 Enum 映射为 guid。想想你现在是否真的需要它。如果没有，请保持简单。
好的，好的。但是，如果到那时，我有一些遗留数据，那么我需要进行一些非常重要的数据库重构。
如果你不这样做怎么办？您将在应用程序生命周期内维护更复杂的解决方案。因此，如果您知道需要复杂性，请引入复杂性。
具有讽刺意味的是，我决定偏离“标准”，因为这是查找而不是实体，因此使用整数 PK 而不是 GUID 似乎更有意义（DBA 无论如何都讨厌）。我觉得一个关于查找与实体建模的全新问题出现了...... :-)