|
锁定老帖子 主题：是谁破坏了枚举类型？
精华帖 (1) :: 良好帖 (0) :: 新手帖 (14) :: 隐藏帖 (1)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2011-05-22
最后修改：2011-05-22
sammor 写道 1、只是为了这样一个需求而去建一张专门的表，好像有点儿大材小用了。 2、编译会确实会转为static final这样的修饰进去，只是如果这样的话，加的setValue()方法里面就不应该可以把value值改变才是呀，但是为什么只有服务端没有被改变值，客户端却被修改掉了呢？ 在前期需求不大的时候, 直接写入应用程序, 后面类型很多的时候使用持久化表. 客户端被修改, 在我看来, 是因为序列化. 具体还得深入再看看, 只是我的一点看法... |
| 返回顶楼 | |
|
发表时间：2011-05-22
我觉得如果基础数据经常变化的,这种需求最好还是建表
建表可以公用啊.不一定就存这个卡类型 比如建表字段 table_name ,col_name,value,value_desc 前台读取的时候通过table_name和col_name来读就行 这样很多基础数据都可以放一个表里维护 |
| 返回顶楼 | |
|
发表时间：2011-05-22
最后修改：2011-05-22
liu.anxin 写道 sammor 写道 1、只是为了这样一个需求而去建一张专门的表，好像有点儿大材小用了。 2、编译会确实会转为static final这样的修饰进去，只是如果这样的话，加的setValue()方法里面就不应该可以把value值改变才是呀，但是为什么只有服务端没有被改变值，客户端却被修改掉了呢？ 在前期需求不大的时候, 直接写入应用程序, 后面类型很多的时候使用持久化表. 客户端被修改, 在我看来, 是因为序列化. 具体还得深入再看看, 只是我的一点看法... 你这个设计有很大的问题, 序列化本身就要保证对象是可被更改的, 你却用在了不可被更改的枚举上 是的，这样破坏性代码确实是写不得的。
private void writeEnum(Enum en,
ObjectStreamClass desc,
boolean unshared)
throws IOException
{
bout.writeByte(TC_ENUM);
ObjectStreamClass sdesc = desc.getSuperDesc();
writeClassDesc((sdesc.forClass() == Enum.class) ? desc : sdesc, false);
handles.assign(unshared ? null : en);
writeString(en.name(), false);
}
我刚才这边做了个测试，把传输的内容显示出来，发现枚举类有自己的传输方式，传输的是这个枚举类的路径，还有这个枚举的实例名，并不会把value的值也传过去。 |
| 返回顶楼 | |
|
发表时间：2011-05-22
luntan08 写道 我觉得如果基础数据经常变化的,这种需求最好还是建表
建表可以公用啊.不一定就存这个卡类型 比如建表字段 table_name ,col_name,value,value_desc 前台读取的时候通过table_name和col_name来读就行 这样很多基础数据都可以放一个表里维护 嗯，对于经常性的变化，确实用这样的方式好点。 |
| 返回顶楼 | |
|
发表时间：2011-05-22
很好 顶
|
| 返回顶楼 | |
|
发表时间：2011-05-23
产品信息存DB，觉得麻烦存配置文件，XML挺好
|
| 返回顶楼 | |
|
发表时间：2011-05-23
典型的乱用枚举，枚举初衷就是是替换以前的static final XXX用的，属于严格的vo。
|
| 返回顶楼 | |
|
发表时间：2011-05-23
最近，我也遇到了类似的疑惑。
之前的接口也是用到了枚举，结果发现，一旦修改枚举，客户端就得替换接口包，这样对客户来说是不必要的，于是改为不用枚举了。 楼主的这个测试个人觉得还是很有意义的，谢谢！ |
| 返回顶楼 | |
|
发表时间：2011-05-23
Angi 写道 最近，我也遇到了类似的疑惑。
之前的接口也是用到了枚举，结果发现，一旦修改枚举，客户端就得替换接口包，这样对客户来说是不必要的，于是改为不用枚举了。 楼主的这个测试个人觉得还是很有意义的，谢谢！ 你的应用场景和我的就用场景是相似的。只有真正碰到问题时，才会思考如何去优化它或是改造它。 |
| 返回顶楼 | |
|
发表时间：2011-05-23
强迫症 强迫症~~
|
| 返回顶楼 | |
