c# - 意见请求 : for static values, 使用枚举或实体更好吗？

Question

我正在努力解决过去几个月一直困扰我的难题。

我和我的同事在一个技术问题上完全不同意，我想听听我们亲爱的社区对此事的看法。

简而言之:

使用枚举(具有潜在的属性，例如“描述”)还是使用实体(具有名称和描述属性)更好？

详情:

在我们的领域模型中，我们有很多微型实体，它们只包含一个 ID、一个名称和一个描述。95% 的情况下，描述等同于名称。

为了便于解释，我将举一个例子:在我们的 Security 实体中，我们有一个 AssetClass 属性。AssetClass 具有静态值列表(“股权”、“债券”等)，并且不会因界面或其他任何内容而发生变化。

问题在于，当您想要获得 Assets 类别为“Bond”的所有证券时，例如，NHibernate 将必须加入 AssetClass 表...并且考虑到 AssetClass 不是唯一的属性，您可以想象所有这些连接对性能的影响。

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

我们的代码中有一些 AssetClass 的硬编码实例及其各自的值和 ID(即 ID 为 1 的股票，ID 为 2 的债券等)，它们与数据库中的内容相匹配:

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();
        }
    }
}

我的解决方案:(我同意 :-))

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

他们反对使用枚举的理由:

• 这不是一个对象，所以你不能扩展它，它不是面向对象的等等。
• 您无法轻易获得描述，或者无法使用“正确的英文”名称(带有空格或符号)，例如“My Value”(在枚举中为“MyValue”)
• 枚举很烂
• 属性糟透了

我反对我们当前解决方案的理由:

• 代码中的 ID 与数据库中的 ID 可能不匹配
• 维护起来要困难得多(我们需要绝对确保我们拥有的每个硬编码值也在数据库中)
• 属性和枚举如果使用得当并适用于像这样的静态值就不会糟透
• 对于“正确的英文”名称，我们还可以使用一个属性，通过一些扩展方法来使用它。

现在，您怎么想？

Answer 1

就我个人而言，我更喜欢第一种解决方案，可能带有一个返回所有值的附加属性。

它更面向对象 - 枚举基本上是“命名数字”，仅此而已。在代码的其他任何地方，状态都存储在属性中——那么为什么要使用属性呢？正如 Eric Lippert 在 blog post comparing the two 中所写，“属性是关于机制的事实”。您基本上是将它们用作提供有关值(value)观的数据的一种方式，我觉得这不对。

就代码和数据库之间的潜在不匹配而言，您反对使用 POCO 的前两个反对意见也不成立 - 因为它们对于枚举也完全相同，不是吗？此外，编写验证数据的测试非常容易 - 如果需要，您甚至可以在启动时这样做。

尚不清楚 AssetClass 的其余部分的作用，但如果它只有一个 private 构造函数，那么您将在以下方面获得枚举的很多好处一组有限的、众所周知的值，但没有枚举基本上只是数字的问题。

事实上，POCO 解决方案在值限制方面优于 - 因为唯一“无效”的 POCO 值是 null，而很容易得出无效的枚举值:

FooEnum invalid = (FooEnum) 12345;

您要到处检查吗？通常，空引用比无效枚举值更早发生爆炸，并且也更容易检查。

我能想到的 POCO 方法的一个缺点是您无法打开它。有很多方法可以解决这个问题，但它们并不是非常令人愉快 - 你基本上必须还有一组众所周知的数字(当然可以是一个枚举)以便一些属性会返回它，你可以打开它。