學員會診之02：SVN協作以及Page類的設計

阿新 • • 發佈：2019-01-13

三層架構的學生管理系統是我們第一個稍微大型的專案：分層、一個解決方案多個Project，所以值得我們停下來好好審查審查。

1.測試SVN伺服器地址

我們的作業要求學員建立自己的SVN伺服器，並且將程式碼commit上去，然後講師進行批改是從原始碼伺服器上獲取程式碼，繼而review。這非常類似於敏捷開發中的同行審查。在企業中，我們一般也是這樣做程式碼審查的。

既然要審查程式碼，那麼第一件事情就是要把程式碼從學生的伺服器上check out下來，所以我第一步就是找學生要劉同學的SVN伺服器地址以及使用者名稱、密碼，這次我們稽核的是另一位劉同學，如下：

上面圖示中，我打了一個叉叉和一個對勾。叉叉的地方是劉同學自己去SVN中copy地址出來的，然後我們要轉換成自己在區域網中的地址才行。

怎麼查自己的本機地址？記得回去敲cmd命令：ipconfig。如果你發現沒有此命令，記得要以管理員身份執行cmd。

緊接著，拿到劉同學的地址，首先測試下是否已經聯通，於是開啟瀏覽器，敲入地址，如下：

在這次連線中，我們發現劉同學在伺服器配置SVN的時候，使用的是https的協議，所以要點選上圖中的“高階”（PS：不同的瀏覽器設定形式不一樣）。

然後點選下圖中的繼續前往

出意外，會彈出使用者名稱和密碼框。這個使用者名稱和密碼是劉同學在SVN伺服器上專門為我設定的。

如果看到下圖，說明已經成功。

2.獲取單個專案原始碼

接下來，讓我們在eclipse中check out程式碼。

首先，點選import

選擇 Project from SVN

點選creat a new respository location

輸入地址。記住，這一步同時要輸入使用者名稱和密碼，然後，記得勾選Save authentication。

點選finish

接下來會問你是否信任連線，直接“Trust Always”，然後下一個頁面選擇Java Project

在接下來的這個頁面，我們要select resource，如下。注意，我們剛才獲取到的地址是：https://192.168.1.125:9443/svn/zuikc/。但是這裡有個問題，因為我們發現我們的專案是在這個地址的子檔案中，所以，我們要輸入全路徑，如下，

下一步，預設finish

然後，彈出這個介面，選擇Java Project

Next之後，讓我們輸入project name，如下

點選finish，這次是真的finish了。

3.獲取全部專案原始碼

在這個作業中，我要求大家將專案分成多個project。上面只是獲取最底層的bean。緊接著我們按照從下到上的次序依次獲取專案。

先common。Common下來後，你大概會看到一些錯誤

為什麼吶？

第一個原因，因為我們在common中用到了jdbc，所以，如果我們建立lib資料夾，將jdbc包引入進來，就會出現找不到包的情況；

第二個原因，即便引入，如果沒有正確匯入到build path中，也會出現錯誤。那怎麼修復？如下：

接著匯入dao，同樣，有可能碰到這樣的問題

重新引入jar包、common和bean吧，

接下來的幾個專案也類似哦。全部完畢後，是這樣的：

4.問題分析之Page類的設計

劉同學的程式碼完成度很高。不過還有一個小小的不完美的地方。我們可以看到在分頁這個部分，劉同學有意識的建立了一個Page類，現在來看看Page類長什麼樣：

package com.zuikc.usermanagement.dao;

public class Page {
    //設定每頁行數
    public static final int PAGE_SIZE = 5;
    //起始行號
    private int startRow;
    //總行數
    private int rows;
    //總頁數
    private int pages;
    //當前頁號
    private int currentPage;
    public int getStartRow() {
        return startRow;
    }
    public void setStartRow(int startRow) {
        this.startRow = startRow;
    }
    public int getRows() {
        return rows;
    }
    public void setRows(int rows) {
        this.rows = rows;
    }
    public int getPages() {
        return pages;
    }
    public void setPages(int pages) {
        this.pages = pages;
    }
    public int getCurrentPage() {
        return currentPage;
    }
    public void setCurrentPage(int currentPage) {
        this.currentPage = currentPage;
    }

}

方向是對的，這裡確實得有一個Page類。

但是放錯了地方：

Page類它不應該是dao層的東西，而是一個特殊的bean。

為什麼說它特殊呢，接下來就要引入第二個問題了。Page類中缺少了東西。最重要的一個東西就是要包裝的型別的列表屬性，比如：List<User>。

為什麼要這個包裝屬性呢？我們可以看一下劉同學的service：

在劉同學的UserService的分頁查詢函式中，直接返回的是List<User>。但是，我們在上層呼叫的時候，除了獲取當前頁的資訊之後，一般還需要獲取：當前是第幾頁、每頁顯示多少條、總共多少頁這樣的資訊。你可能會說：簡單啊，上層針對這些屬性多呼叫幾個這樣的service方法不就行了？

行是行。但是上層在設計上只是負責顯示的，我們應該讓這些邏輯上的工作放置到service層中，也就是說：在呼叫queryUsersByPage的時候，應該將這些屬性一次性返回！那怎麼返回，要知道方法只能有一個返回值。沒辦法了，我們只能把這些屬性，連同List<User>封裝到一個類裡，比如Page裡返回。

於是，Page類變成了：