zoukankan      html  css  js  c++  java
  • pojo类对应的就是数据库中的表,pojo类属性类型一定要用包装类Integer等

    pojo类对应的就是数据库中的表,pojo类属性类型一定要用包装类Integer等

    pojo类对应的就是数据库中的表,pojo类属性类型一定要用包装类Integer等

    pojo类对应的就是数据库中的表,pojo类属性类型一定要用包装类Integer等

    如果值有可能是空  就必须用包装类

    如果值有可能是空  就必须用包装类

    如果值有可能是空  就必须用包装类

    如果值有可能是空  就必须用包装类

    手册给出的解释如下:

    说明:POJO 类属性没有初值是提醒使用者在需要使用时,必须自己显式地进行赋值,任何NPE 问题,或者入库检查,都由使用者来保证。

    正例:数据库的查询结果可能是 null,因为自动拆箱,用基本数据类型接收有 NPE 风险。

    反例:比如显示成交总额涨跌情况,即正负 x%,x 为基本数据类型,调用的 RPC 服务,调用不成功时,返回的是默认值,页面显示:0%,这是不合理的,应该显示成中划线-。所以包装数据类型的 null 值,能够表示额外的信息,如:远程调用失败,异常退出。

    手册给出的解释如下:

    说明:POJO 类属性没有初值是提醒使用者在需要使用时,必须自己显式地进行赋值,任何NPE 问题,或者入库检查,都由使用者来保证。

    正例:数据库的查询结果可能是 null,因为自动拆箱,用基本数据类型接收有 NPE 风险。

    反例:比如显示成交总额涨跌情况,即正负 x%,x 为基本数据类型,调用的 RPC 服务,调用不成功时,返回的是默认值,页面显示:0%,这是不合理的,应该显示成中划线-。所以包装数据类型的 null 值,能够表示额外的信息,如:远程调用失败,异常退出。

    简单来说就是我们如果自定义了一个Student类,其中有一个属性是成绩score,如果用Integer而不用int定义,一次考试,学生可能没考,值是null,也可能考了,但考了0分,值是0,这两个表达的状态明显不一样

    简单来说就是我们如果自定义了一个Student类,其中有一个属性是成绩score,如果用Integer而不用int定义,一次考试,学生可能没考,值是null,也可能考了,但考了0分,值是0,这两个表达的状态明显不一样

    我也没有仔细推敲过
    但是觉得有以下几个方面:
    1. 如果这个字段可以为空,那么就用封装类型,这样的话可以得到NULL ,而不是 0 或者其他值
    2. 如果使用封装类型的话,在做po的比较的时候 ,特别是该属性的比较的时,一定要用equals或者用他们的 value来比较, 因为是对象
    3. 其实还是根据实际情况来做判断 没有优劣 只有适不适合

    Java的封装类型和原始类型的区别?那种性能好?

    Java的封装类型和原始类型的区别?在JavaWeb程序当中,pojo(javabean)实体类中,是声明为封装类型好还是原始类型好?(比如:int-Integer)  
    例如:  
    复制代码
    public class User{
    private int id;
    private Integer id1;
    }
     
    int 默认初始化为0;Integer初始化为null;  
    如果在web前端通过ajax请求到后台的时候,参数传递为 id=&di1=  
    后台获取参数值时:  
    id=1  
    id1=null  
    然后,保存到数据库时,Integer是不是要拆包为int类型?  
    请问声明为那种类型更好,更适合程序的处理和性能?  
     
    请问各位Java大神分析分析,求指导!

  • 相关阅读:
    【转】Dalvik虚拟机的启动过程分析
    【转】Android 之ActivityThead、ActivityManagerService 与activity的管理和创建
    【转】应用程序的入口是ActivityThread
    【转】Android中Application类用法
    【转】360浏览器极速与兼容模式的解释
    操作系统学习(七)--操作系统之外设显示器和键盘
    操作系统学习(六)-- 虚拟内存(页面置换算法)
    操作系统学习(五)-- 操作系统之内存管理
    操作系统学习(四)-- 操作系统之进程同步和死锁
    数据库系统学习(八)-SQL语言与数据库完整性和安全性
  • 原文地址:https://www.cnblogs.com/panxuejun/p/7279493.html
Copyright © 2011-2022 走看看