Springboot2 Jpa關於分頁PageRequest

公司作項目,都是使用Mybatis, 我的不太喜歡xml的方式,天然也嘗試無xml的Mybatis,在以前寫的一篇多數據源+Mybatis+無xml配置.html

不廢話,本篇記錄使用JPA遇到的問題筆記.java

 

寫到Dao層,繼承JpaRepository,實現分頁時候的問題.spring

public interface HelloRepository extends JpaRepository<Hello,Integer>

單元測試的時候,用到了PageRequestapi

PageRequest pageRequest=new PageRequest(0,10);

這明顯是過時了,不能容忍的強迫症犯發,點進去API查看安全

發現3個構造器都@Deprecated註解,說明過期的調用方式,不推薦使用.dom

再往下看,能夠找到static的方法,是用來建造PageRequest對象的,內部調用的也是原來的構造器.函數

把原來的 new PageRequest 改爲 PageRequest.of(0,10);單元測試

有3個重載 對應 3個構造器.學習

官方API說明: since 2.0, use of(...) instead.測試

2.0版本後,使用 of(...) 方法代替 PageRequest(...)構造器

URL :  ↓↓↓

https://docs.spring.io/spring-data/commons/docs/current/api/org/springframework/data/domain/PageRequest.html

 

擴展學習一下API的設計思想

分析: PageRequest構造器中的參數最可能是4個參數,其中必填的是2個參數(page,rows)

另外2個參數是選填direction(正序倒序),properties(排序字段)

設計這該類的構造器的方法有幾種方案:

1.重疊構造器模式

2.JavaBeans模式

3.構建器模式

其餘.......

重疊構造器模式

構建結構 : 由參數少的構造器參數多的構造器方向調用, 最終調用參數多的構造器建立對象.

好處: 只要有必要參數,就能夠建立對象; 若是還知道了選填的控制參數,就能夠選擇性的建立可控的對象

壞處: 若是參數多了,就是一大坨,一坨接一坨,閃閃發光

public class LotShit {
    private Double wight;
    private String color;
    private String whoS;
    private boolean sweet;

    public LotShit(Double wight) {
        this(wight,"golden");
    }

    public LotShit(Double wight, String color) {
        this(wight,color,"大黃");
    }

    public LotShit(Double wight, String color,String whoS) {
        this(wight,color,whoS,true);
    }

    public LotShit(Double wight, String color, String whoS, boolean sweet) {
        this.wight = wight;
        this.color = color;
        this.whoS = whoS;
        this.sweet = sweet;
    }
}

 

JavaBeans模式

構建結構 : 遵循特定規則的java類,必須有一個無參的構造函數、屬性必須私有化private、私有化的屬性必須經過公有類型的方法(get/set)對外暴露

好處 : 建立簡單,想要什麼本身加什麼

壞處 : 構造過程能夠被set改變字段值,不能保證其安全

public class LotShit {
    private Double wight;
    private String color;
    private String whoS;
    private boolean sweet;
    
    public LotShit(){}

    //getter & setter ...
}

 

構建器模式

構建結構 : 一個複雜對象的構建和表示分離,使得一樣的構建過程能夠創造建立不一樣的表示

好處 : 能夠靈活構造複雜對象實例,適用於多個構造器參數,且參數包含必選和可選參數

壞處 : 寫起來複雜了,構建實例成本高了

只有2個參數,仍是不要用了,若是你不是閒得慌的話

public class LotShit {
    private Double wight;
    private String color;
    private String whoS;
    private boolean sweet;

    private LotShit(Shit shit) {
        this.wight=shit.wight;
        this.color=shit.color;
        this.whoS=shit.whoS;
        this.sweet=shit.sweet;
    }

    public static class Shit {
        private Double wight;
        private String color;
        private String whoS;
        private boolean sweet;


        public LotShit create() {
            return new LotShit(this);
        }

        private Shit setWight(Double wight) {
            this.wight = wight;
            return this;
        }

        private Shit setColor(String color) {
            this.color = color;
            return this;
        }

        private Shit setSweet(boolean sweet) {
            this.sweet = sweet;
            return this;
        }

        private Shit setWhoS(String whoS) {
            this.whoS = whoS;
            return this;
        }
    }
}

 

說了這麼多,彷佛PageRequest用的靜態方法代替構造器的方式和上面沒有什麼關係,哈哈哈

這裏區別於工廠方法模式中的,它只是一個靜態的方法,工廠方法模式一般有產品和工廠兩部分

這樣使用的分析一下:

1. 能夠自定義方法名字,區別多個構造器是幹什麼用的,構建的階段什麼的,明顯PageRequest.of用的都同樣,統一與構造器結構也不錯,哈哈哈

2. 能夠充分利用多態,使代碼更具備可擴展性,好比返回子類的實例,構造器則不行

3. 同樣具備重疊構造器的優勢

4. 若是該類中沒有public或protected的構造器,該類就不能使用靜態方法子類化

5.基於第4點,策略模式說到應該多用組合而不是繼承,當一個類不能子類化後,組合將是你惟一的選擇

PS: 靜態工廠方法本質上就是一個靜態方法

 

 

---------------------------------------------------------------

相關文章
相關標籤/搜索