c# – 请求意见:对于静态值,使用枚举或实体是否更好?
我正在努力解决过去几个月一直在唠叨我的困境.
我和我的同事对技术问题完全不同意,我希望我们心爱的社区对此事的看法. 简而言之: 是否最好使用枚举(具有潜在的属性,如“描述”),或使用实体(具有名称和描述属性)? 详情如下: 在我们的域模型中,我们有很多迷你实体,只包含Id,名称和描述. 为了便于解释,我将采用众多示例中的一个:在我们的Security实体中,我们有一个AssetClass属性. 问题在于,当你想要获得资产类别为“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(); } } } 我的解决方案:(我同意:-)) 用枚举替换这些实体,如果我们需要描述字段,请使用属性. 他们理性反对使用枚举: >这不是一个对象,所以你不能扩展它,它不是面向对象的,等等. 我对现有解决方案的理性: >我们可能在代码中的ID与数据库中的内容不匹配 现在,你怎么想? 解决方法
我个人更喜欢第一个解决方案,可能还有一个返回所有值的附加属性.
它更多OO – 枚举基本上是“命名数字”,就是这样.代码中的其他任何地方,状态都存储在属性中 – 所以为什么要使用属性呢?正如Eric Lippert在blog post comparing the two中写道的那样,“属性是关于机制的事实”.您基本上使用它们作为提供有关值的数据的方式,而这对我来说感觉不对. 你对代码和数据库之间潜在不匹配使用POCO的前两个反对意见也不正确 – 因为它们对于枚举也是完全相同的,不是吗?此外,编写一个验证数据的测试非常容易 – 如果你愿意,你甚至可以在启动时这样做. 目前还不清楚你的AssetClass的其余部分是做什么的,但是如果它只有一个私有的构造函数,那么你可以从有限的,众所周知的一组值中获得枚举的很多好处,但是没有枚举的问题.基本上只是数字. 实际上,POCO解决方案在值限制方面优于枚举 – 因为唯一的“无效”POCO值为空,而很容易产生无效的枚举值: FooEnum invalid = (FooEnum) 12345; 你打算到处检查吗?通常,空引用比无效的枚举值早得多,并且更容易检查. 我在POCO方法中可以想到的一个缺点是你不能打开它.有办法解决这个问题,但它们并不十分令人愉快 – 你基本上还必须拥有一套众所周知的数字(当然可能是一个枚举),以便某些属性可以返回,你可以切换在上面. (编辑:李大同) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |