V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
rason
V2EX  ›  Java

大家是怎么处理类型和类型描述的?

  •  
  •   rason · 2017-03-03 08:58:18 +08:00 · 2991 次点击
    这是一个创建于 2619 天前的主题,其中的信息可能已经有所发展或是发生改变。
    比如一个实体类 User ,有个性别属性, 1 表示男, 0 表示女。前端显示时,当然是显示文字,请问大家是在哪一层转换的。因为有太多的实体需要将数据库中保存的类型转成描述了。
    24 条回复    2017-03-14 21:19:57 +08:00
    MiguelValentine
        1
    MiguelValentine  
       2017-03-03 09:10:22 +08:00
    (!sex)?"女":"男";
    前端啊。
    JamesRuan
        2
    JamesRuan  
       2017-03-03 09:13:24 +08:00
    变量名为 is_man ,在视图层转换。
    变量名是 gender ,则应该直接把文字保存在数据库。
    如果变量名是 gender ,还存 0 和 1 ,应该把设计数据库的人抓出来打一顿(逃
    fwrq41251
        3
    fwrq41251  
       2017-03-03 09:14:07 +08:00
    jpa AttributeConverter ,业务代码里应该只有枚举,没有 0,1 啥的
    340244120
        4
    340244120  
       2017-03-03 09:14:49 +08:00 via Android
    方案一 数据在显示层之前做转换,枚举比较多的话,可以用工具类进行转换。
    方案二 显示层处理。缺点是前端工作量更多。优点是数据传输量相对少;前端快速实现多国语言切换等
    rason
        5
    rason  
    OP
       2017-03-03 09:27:26 +08:00
    @MiguelValentine 要转换的地方太多的话会累死前端,而且还得沟通告诉前端啥对应啥。
    rason
        6
    rason  
    OP
       2017-03-03 09:29:07 +08:00
    @340244120 多一个实体需要转换需要修改工具类,感觉挺麻烦的,我想要的效果是能够轻松统一处理多处的转换。
    rason
        7
    rason  
    OP
       2017-03-03 09:30:31 +08:00
    @JamesRuan 直接数据库保存文字是一个好的方案?这个我不太确定,不知道大家是怎样用的。
    JamesRuan
        8
    JamesRuan  
       2017-03-03 09:37:02 +08:00
    @rason 多国语言支持可以存专门的翻译用表,至少我知道 EVE 的数据库是这么设计的。

    关键点在于,**别把 0->女 1->男这样的数据关系不当数据**。既然是数据,存数据库自然是最直接的。

    说优化传输量的可以省省了,这明明是“过早优化”,减少传输数据量一个 gzip 就能搞定。

    说优化储存量的,你要不用 is_man 这样的变量名,存 boolean ,要不就老老实实存字符类型。说不定哪天有个需求要求支持男女外的其他性别呢?( facebook ?)
    shakespaces
        9
    shakespaces  
       2017-03-03 09:47:37 +08:00
    一般来说给前端吧
    MiguelValentine
        10
    MiguelValentine  
       2017-03-03 09:47:39 +08:00
    @rason 关键前端在设置性别的时候,肯定传 0/1 吧。你们的业务不会传回来男女吧。刚好前端双绑定。
    kanezeng
        11
    kanezeng  
       2017-03-03 09:52:33 +08:00
    看情况吧,某些极端情况下,为了灵活调整,在数据库里建一个专门的对应表也可以吧。
    以性别为例(当然这个不是特别极端,所以不是很合适,看看意思就好),比如建个性别表,有 id ,有描述,里面可以随时添加,比如:男,女,不男不女,变性,保密。。。。。。
    用户表就存性别 id 就好了,传给前端的用户数据可以有 id ,也可以附带一项比如 gender_desc 把对应的描述加上啊。
    rason
        12
    rason  
    OP
       2017-03-03 10:01:13 +08:00
    @MiguelValentine 嗯,这样做就是把锅丢给前端来玩了,所以想看看大家有没有什么好的解决方法。
    rason
        13
    rason  
    OP
       2017-03-03 10:02:16 +08:00
    @kanezeng 恩,你说的方式我在工作中都有见过或者用到过,但是总感觉有点不足,所以想问问大家有什么更好的方式。
    R18
        14
    R18  
       2017-03-03 10:06:03 +08:00
    前端
    moguiyu
        15
    moguiyu  
       2017-03-03 10:36:16 +08:00
    你这个举例,要是在某国,肯定会被一大波政治正确的多性别人士挑战,笑
    zk123
        16
    zk123  
       2017-03-03 10:50:52 +08:00
    ## 为啥不直接在 user 中存男女
    otakustay
        17
    otakustay  
       2017-03-03 13:02:42 +08:00
    前端转换,我的原则永远是面向用户的转换就在最靠近用户的层,如果前端还有 MVC 分层,那么就在 V 转换,这是架构的原则而不是丢锅,我作为前端只会尽量把这种转换的工作往自己这边揽,相比之后的沟通更新升级要省力多了
    前端里实现枚举这样的结构用于做这些转换
    QAPTEAWH
        18
    QAPTEAWH  
       2017-03-03 13:05:34 +08:00   ❤️ 1
    不好好用个 enum 表示用什么 0/1...

    当然 0/1 挺形象的(逃
    willakira
        19
    willakira  
       2017-03-03 13:52:34 +08:00 via iPhone
    Gender 用 enum 最好 即便不是为了政治正确 也要考虑一下有人不想披露自己性别

    至少有男 女 不详

    一般我会在写到数据库的前一层(包着数据库的服务那块)才转换
    好处是
    - 数据库对于服务来说是透明的
    - 每个数据库自己有自己的 db service 管编码解码
    joysir
        20
    joysir  
       2017-03-03 14:04:51 +08:00
    在使用 jsp 时,我会在实体定义一个变量: gengerName , getter 里面 做转换。然后页面直接使用。
    如果是接口,则直接返回 0/1 , 很形象
    jsq2627
        22
    jsq2627  
       2017-03-03 15:59:13 +08:00 via iPhone
    c#的 entity framework 这方面处理很好。应用层全部是 enum 的, enum 到数字的转换由 orm 完成了。
    darrenfang
        23
    darrenfang  
       2017-03-04 10:00:10 +08:00 via iPhone
    @jsq2627 hibernate 也可以
    ibufu
        24
    ibufu  
       2017-03-14 21:19:57 +08:00
    ['女','男'][sex]
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   787 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 27ms · UTC 22:37 · PVG 06:37 · LAX 15:37 · JFK 18:37
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.