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

Question

我正在努力解决过去几个月一直在唠叨我的困境.

我和我的同事对技术问题完全不同意,我希望我们心爱的社区对此事的看法.

简而言之:

是否最好使用枚举(具有潜在的属性,如"描述"),或使用实体(具有名称和描述属性)？

详情如下:

在我们的域模型中,我们有很多迷你实体,只包含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")
• 枚举很糟糕
• 属性很糟糕

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

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

现在,做你认为呢？

Answer 1

我个人更喜欢第一个解决方案,可能还有一个返回所有值的附加属性.

它更多OO - 枚举基本上是"命名数字",就是这样.代码中的其他任何地方,状态都存储在属性中 - 所以为什么要使用属性呢？正如Eric Lippert在一篇比较两者的博客文章中所写,"属性是关于机制的事实".您基本上使用它们作为提供有关值的数据的方式,而这对我来说感觉不对.

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

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

实际上,POCO解决方案在值限制方面优于枚举 - 因为唯一的"无效"POCO值为空,而很容易产生无效的枚举值:

FooEnum invalid = (FooEnum) 12345;

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

我在POCO方法中可以想到的一个缺点是你不能打开它.有办法解决这个问题,但它们并不十分令人愉快 - 你基本上还必须拥有一套众所周知的数字(当然可能是一个枚举),以便某些属性可以返回,你可以切换在上面.