简而言之：

是否最好使用枚举（具有潜在的属性，如“描述”），或使用实体（具有名称和描述属性）？

详情：

在我们的域模型中，我们有很多迷你实体，只包含Id，名称和描述。 95％的情况下，描述等于名称。

为了解释起见，我将采用其中一个例子：在我们的Security实体中，我们有一个AssetClass属性。 AssetClass具有静态值列表（“Equity”，“Bond”等），并且不会从界面或其他任何内容发生变化。

问题在于，当你想要获得资产类别为“Bond”的所有证券时，NHibernate将不得不加入AssetClass表......并且考虑到AssetClass不是唯一这样的属性，你可以想象所有这些联接的性能影响。

我们目前的解决方案:(我不同意）：

我们的代码中有一些硬编码的AssetClass实例及其各自的值和ID（即Id为1的Equity，Id为2的Bond等），与数据库中的内容相匹配：

public partial class AssetClass
{
    static public AssetClass Equity = new AssetClass(1, "Equity", "Equity");
    static public AssetClass Bond = new AssetClass(2, "Bond", "Bond");
    static public AssetClass Future = new AssetClass(3, "Future", "Future");
    static public AssetClass SomethingElse = new AssetClass(4, "Something else", "This is something else");
}

我们还制作了一个特殊的NHibernate类型（下面的代码，如果你感兴趣的话），它允许我们通过加载那个硬编码的实例而不是去数据库来避免NHibernate做连接：

using System;
using System.Data;
using System.Data.Common;
using NHibernate.Dialect;
using NHibernate.SqlTypes;
using NHibernate.Type;

namespace MyCompany.Utilities.DomainObjects
{
    public abstract class PrimitiveTypeBase<T> : PrimitiveType where T : class, IUniquelyNamed, IIdentifiable
    {
        private readonly PrimitiveTypeFactory<T> _factory;

        public PrimitiveTypeBase() : base(SqlTypeFactory.Int32)
        {
            _factory = new PrimitiveTypeFactory<T>();
        }

        public override string Name
        {
            get { return typeof(T).Name; }
        }

        public override Type ReturnedClass
        {
            get { return typeof(T); }
        }

        public override Type PrimitiveClass
        {
            get { return typeof (int); }
        }

        public override object DefaultValue
        {
            get { return null; }
        }

        public override void Set(IDbCommand cmd, object value, int index)
        {
            var type = value as T;
            var param = cmd.Parameters[index] as DbParameter;
            param.Value = type.Id;
        }

        public override object Get(IDataReader rs, int index)
        {
            return GetStaticValue(rs[index]);
        }

        public override object Get(IDataReader rs, string name)
        {
            return GetStaticValue(rs[name]);
        }

        private T GetStaticValue(object val)
        {
            if (val == null)
            {
                return (T)DefaultValue;
            }

            int id = int.Parse(val.ToString());
            T entity = _factory.GetById(id); // that returns, by reflection and based on the type T, the static value with the given Id

            if (entity == null)
            {
                throw new InvalidOperationException(string.Format("Could not determine {0} for id {1}", typeof (T).Name, id));
            }
            return entity;
        }

        public override object FromStringValue(string xml)
        {
            return GetStaticValue(xml);
        }

        public override string ObjectToSQLString(object value, Dialect dialect)
        {
            var type = value as T;
            return type.Id.ToString();
        }
    }
}

我的解决方案:(我同意： - ））

用枚举替换这些实体，如果我们需要描述字段，请使用属性。我们也可能对数据库有一个约束，以确保您不能存储与枚举不匹配的随机值。

他们理性反对使用枚举：

这不是一个对象，所以你不能扩展它，它不是面向对象的等等。
您无法轻易获得描述，或拥有“正确的英文”名称（带有空格或符号），例如“我的价值”（在枚举上将是“MyValue”）
Enums糟透了
属性很糟糕

我对现有解决方案的理性：

我们可能在代码中的ID与数据库中的内容不匹配
维护起来要困难得多（我们需要确保我们拥有的每个硬编码值都在数据库中）
如果使用得当，属性和枚举不会很糟糕，对于像这样的静态值
对于“正确的英语”名称，我们也可以使用一个属性，使用一些扩展方法来使用它。

现在，你的想法是什么？

Answer 1

我个人更喜欢第一个解决方案，可能还有一个附加属性，它返回 all 的值。

更多OO - 枚举基本上是“命名数字”，就是这样。代码中的其他任何地方，状态都存储在属性中 - 所以为什么要使用属性呢？正如Eric Lippert在blog post comparing the two中所写，“属性是关于机制的事实”。您基本上使用它们作为提供有关值的数据的方式，而这对我来说感觉不对。

在代码和数据库之间可能存在不匹配的情况下使用POCO的前两个异议也不正确 - 因为它们对于枚举也是完全相同的，不是吗？此外，编写一个验证数据的测试非常容易 - 如果你愿意，你甚至可以在启动时这样做。

目前还不清楚AssetClass的其他内容是做什么的，但如果它只有一个私有构造函数，那么你就可以获得枚举的许多好处，众所周知的一组值，但没有问题，枚举基本上只是数字。

事实上，就价值限制而言，POCO解决方案更好 - 因为唯一的“无效”POCO值为空，而很容易产生无效的枚举值：

FooEnum invalid = (FooEnum) 12345;

你打算到处检查吗？通常，空引用比无效的枚举值早得多，并且更容易检查。

我在POCO方法中可以想到的一个缺点是你无法打开它。有很多方法，但它们并不十分令人愉快 - 你基本上必须还有一套众所周知的数字（当然可能是枚举）所以有些属性会返回，你可以打开它。

Answer 2

我真的不喜欢这两种选项，因为代码和数据库之间ID可能不匹配。你实际上指出了这一点，但由于某种原因，似乎认为如果你使用枚举这个问题会消失，实际上你会有完全相同的事情吗？

如果我必须在两者之间做出选择，我会选择当前的实施，因为Jon Skeet已经提到过。

但是，我认为最好的方法是创建一个普通的类并从数据库中获取项目，然后针对属性的程序。我刚才写了这篇文章来解释我的意思：Program against attributes

Answer 3

我个人更喜欢将枚举存储为数据库中的字符串。您可能需要的任何其他信息都可以在其自己的表中使用枚举类型和值作为键。我不会将描述存储为属性。将Enum.SomeValue转换为包含“Some Value”

的字符串也很简单

我更喜欢枚举主要是因为它们为您提供了编译器支持，并且可以通过简单的重构轻松更改添加新值，其中字符串值可以在值更改时产生一些不错的隐藏错误。

这个

if(obj.EnumValue == Enum.Value)

比这更好

if(obj.Value == "SomeValues")

我使用了Gluent-nhibernate附带的GenericEnumMapper，但是如果你使用的是hibernate，你可以使用EnumString类型。这提供了一种很好的方法，可以将枚举作为数据库中的字符串，这样您就无法访问代码，因此您可以读取数据。

意见请求：对于静态值，使用枚举或实体更好吗？

简而言之：

详情：

我们目前的解决方案:(我不同意）：

我的解决方案:(我同意： - ））

他们理性反对使用枚举：

我对现有解决方案的理性：

3 个答案: