我把状态放在数据库里
  回复  引用    

放在数据库中取出来的时候就比较麻烦了。有时候需要联合的表可能很多。
放在库中叶建议多个小表放在一张表中。使用一个字段区分，减少页数。

怎么没说那两个方法有什么用处呢。
  回复  引用  查看    

假如有变化怎么办,修改程序,增加枚举?
  回复  引用  查看    

http://www.codeproject.com/useritems/enumdatabinding.asp
  回复  引用    

恩
写成
CustomerQuery = 0x1,
CustomerOrdered = 0x2,
ReceiverCustomerPayment = 0x4,
.
.
.更专业。这样可以更方便进行enum的位运算
还有你上面那2个mm很靓阿，哪个公司的？:)
  回复  引用  查看    

回楼上，那些mm是微软请来做封面的
  回复  引用  查看    

我10分钟前刚在考虑怎么重构以前得代码，和楼主差不多得问题，是一个服务case得状态，以前是用属性做得，isopened之类，感觉非常不好，刚才想到得主意也是枚举，呵呵。
不过switch看起来不大美观，我还在考虑能否用啥模式，把switch也去掉。
  回复  引用  查看    

搞笑，直接用键值对就可以了
key value
key1 value1
key2 value2

增加多少都可以
  回复  引用  查看    

http://www.cnblogs.com/hilite/archive/2006/03/28/360793.html
  回复  引用  查看    

除了方便代码维护，在.NET中枚举是一种强类型，提高了代码的安全机制。
  回复  引用  查看    

@东吴居士
很感谢你的建议，我设计的时候也考虑这问题，所以每个值都是上个值的两倍，这与二进制有关系的

@beyondjay
我也想过这问题，但暂时想到更好的方法

@布尔
请教一下，如何使用 key value ？


  回复  引用  查看    

@sunrise
其实用一张表来存放也是可以的，可以用到缓存，这与设计模式的单态模式有点像，你也可以考虑用这种方法，效率也很高，只向数据库读取一次。

@暗香浮动
不大清楚你想什么效果，这样的状态只有别人表引用外键里才用到的呀，有关使用状态的表，都是得查询的。
  回复  引用  查看    

@SouthSea
使用数据字典会更容易维护
  回复  引用  查看    

@菌哥
我觉得订单的状态一般都不会修改的，但增加就有可能，如果是修改，就只修改GetOrderStateString(OrderState state)这个方法就行了，如果要增加就枚举增加后再修改GetOrderStateString(OrderState state)这个方法。
因为在数据中已经保存着以前的状态码，不可能去修改枚举的值的，就算你是用数据库表也是一样。
我个人认为，如果要修改或增加一种订单状态的话，说明前期的需求没做好，假如第一个版本出来了后，客户再提出订单状态要增加，那只能是开发第二个版本了，呵呵！
  回复  引用  查看    

如果你考虑到日后要支持国际化，那么中文的字符串就不要hard-coded，而应该放在资源文件中，那么这个例子就更完美了。
  回复  引用  查看    

去看看coding standard,这种给枚举负值的方法是很不认同的
  回复  引用  查看    

return hs[OrderState.Invalid]
  回复  引用  查看    

为何不考虑用字典维护呢?
  回复  引用  查看    

我觉得用一个配置文件来存储这些值更好!
假如增加了一个枚举,你还要改程序吗?
  回复  引用  查看    

可以把状态放数据库里，使用一方法动态读出来，枚举。只要读一次就可以了。同时也解决了硬编码的问题。
我的意思是说，把数据字典和枚举同时用上，才是完美的解决方案。

BTW:楼上不说我还没在意，仔细一看，那俩MM还真的很耐看。
  回复  引用  查看    

@tips
你推荐的这篇文章太好了，比以上所有解决方案都简单：）只是用了一点反射，可能性能会受一些影响。
http://www.codeproject.com/useritems/enumdatabinding.asp
  回复  引用  查看    

如果存在数据库中,也可以使用enum
OrderState o = (OrderState) Enum.Parse(typeof(OrderState), dataReader["orderstate"].tostring(), true);
  回复  引用  查看    

一、所谓用代码表，如存储在数据库里，是使用在既定的逻辑之上，他的增删不会多逻辑产生影响，如国家代码、邮政编码。

二、而枚举类型的使用，当业务逻辑发生了变化，必定会修改枚举类型，也必然会导致程序的修改。如文中提到的状态，当添加状态的时候，代码文字不管存储在什么地方都要修改程序。

而楼主提到的问题就是第二种情况，是由于UI上需要显示枚举所表示的意义。放在数据库中或者给枚举加property都可以，但考虑到需要访问访问数据库，建议显示文字放到程序里，但是楼主的方案维护成本较高，用反射方法较好。
http://www.cnblogs.com/hilite/archive/2006/03/28/360793.html
至于国际化的问题，能有几个项目需要的？如果是产品是可以考虑的。
  回复  引用  查看    

LZ说一下GetHashCode() 这个方法的用途如何？
  回复  引用  查看    

大尾巴狼的方法和TIPS推荐的方法如出一辙，但狼兄比codeproject的文章要早了一年，赞！

  回复  引用  查看    

这个也要放首页?...
  回复  引用  查看    

@东吴居士
是Blog模板自带的哈，呵呵
  回复  引用  查看    

不知道楼主说的GetHashCode到底怎么个经常用法.对于非常固定的只有几个的数据用枚举标识是很好的一种方法.至于UI的显示上,可以使用Attribute的方式来做,我觉得这样比直接在GetOrderStateString中写Switch语句要好.
  回复  引用  查看    

这个也要放首页?... 根据实际情况来选择，枚举或数据库。我的建议就是数据库里有状态表方便查询，同时又使用枚举值方便编码。不过现在用LINQ的话，可以考虑把数据库表取消了。
  回复  引用    

为什么不直接用中文当枚举值？ 这样就不用那个丑陋的switch 了。

http://www.cnblogs.com/waitrabbit/archive/2006/09/26/515213.html

  回复  引用  查看    

说到枚举，我正郁闷呢～～～一个同事居然说没有听说过枚举～～～无敌啊～～没用过好说，连听都没听过？

另外，这个放首页，合适？
  回复  引用  查看    

我把状态放在数据库里
  回复  引用    

2的n次方好，复合状态（如果有的话）很好判断……
  回复  引用  查看    

学习ing!!!!!!!
  回复  引用  查看    

一般情况下，这些值是用枚举来解决！

但对于类型太多的情况下是不适合的！
  回复  引用    

专业点 还是放在数据库里 因为这种状态随着业务更改会越来越多,如果每种单据都作个枚举,代码量会明显增多
比如做个数据字典,存在表里,然后用个存储过程获取,之后变的只是往表里插数据,几乎不用改程序.

  回复  引用  查看    

@shenba
真的不用该代码么？
如楼主的例子，添加了一个新值，程序能不改么？？

  回复  引用  查看    

@shenba
这只是一个种解决方法而已
像楼上有很多朋友都说到一些解决方法
包括你的说的都很有道理
工作经验你比我丰富
还得多向你请教呢
  回复  引用  查看