Giáo trình Spring Boot MVC và REST API · Chương 7/12: Tìm kiếm, phân trang và tài liệu · Bài 15/28 · Biên soạn tháng 10/2026.

Mục tiêu bài học

Xử lý từ khóa, giới hạn kích thước trang, giữ bộ lọc khi chuyển trang và tạo thứ tự ổn định.

Đừng lấy tất cả dữ liệu rồi cắt trong Java

Danh sách ít bản ghi có thể che giấu cách làm tốn tài nguyên. Với phân trang, database chỉ trả phần dữ liệu cần cho trang hiện tại, còn Page chứa thêm tổng số phần tử và số trang. Spring Data thực hiện truy vấn nội dung và có thể cần truy vấn đếm; với dữ liệu rất lớn, ta sẽ cân nhắc Slice hoặc keyset pagination ở mức nâng cao.

Mẫu dùng page bắt đầu từ 0, size từ 1 đến 50. Client không được yêu cầu size=100000 để tải mọi thứ vào bộ nhớ. q được strip để bỏ khoảng trắng đầu cuối. Tên phương thức findByTitleContainingIgnoreCase thể hiện tìm chứa không phân biệt hoa thường, nhưng hành vi chi tiết còn phụ thuộc database và collation.

Tệp trong mã nguồn mẫu: src/main/java/com/hocvietcode/academy/CourseService.java. Đoạn dưới được trích từ tệp này; xem bản tải về để có đủ import và phần còn lại.

public Page<CourseDto> search(String q,int page,int size,String sort){
    if(page<0 || size<1 || size>50) throw new IllegalArgumentException("Trang hoặc kích thước không hợp lệ");
    String field=List.of("id","title","price").contains(sort)?sort:"id";
    return courses.findByTitleContainingIgnoreCase(q==null?"":q.strip(),PageRequest.of(page,size,Sort.by(field).ascending().and(Sort.by("id")))).map(CourseDto::from);
}

Sort cần danh sách cho phép

Client gửi sort=title hoặc price, nhưng không được tự quyết định bất kỳ tên trường hoặc câu SQL nào. Service chọn từ id, title, price; giá trị không được hỗ trợ quay về id. Có thể chọn trả 400 thay vì fallback, miễn hợp đồng rõ ràng và được kiểm thử.

Khi nhiều khóa học có cùng giá, thêm id làm tiêu chí phụ giúp thứ tự xác định hơn. Phân trang offset vẫn có thể xê dịch nếu dữ liệu được thêm/xóa trong lúc người dùng chuyển trang; tiêu chí phụ không biến nó thành một ảnh chụp cố định của toàn bộ dữ liệu.

Giữ q, size và sort trong liên kết

Nếu đang tìm Java rồi bấm trang tiếp theo nhưng URL mất q, người dùng sẽ thấy danh sách hoàn toàn khác và tưởng phân trang lỗi. Mỗi liên kết phải mang bộ lọc hiện tại. Khi đổi từ khóa hoặc sort, form tìm kiếm không gửi page cũ để quay lại trang đầu.

Đoạn dưới là phần liên kết của template list. Chỉ render nút trước hoặc tiếp khi Page cho biết có trang tương ứng. Với kết quả rỗng, giao diện hiển thị một trạng thái dễ hiểu thay vì trang 1/0.

<a th:if="${result.hasPrevious()}"
   th:href="@{/courses(page=${result.number-1},size=${result.size},q=${q},sort=${sort})}">Trước</a>
<a th:if="${result.hasNext()}"
   th:href="@{/courses(page=${result.number+1},size=${result.size},q=${q},sort=${sort})}">Tiếp</a>

Kiểm tra cả URL lẫn nội dung

Chọn size=1 trên dữ liệu mẫu để thấy ít nhất hai trang. Tìm một từ khóa phù hợp, bấm tiếp và kiểm tra URL vẫn giữ q. Thử page=-1 và size=51 phải nhận lỗi 400 thay vì truy vấn không giới hạn. Nếu page vượt tổng số trang, mẫu trả một trang rỗng; sản phẩm có thể chọn redirect về trang cuối hoặc báo rõ trạng thái.

API dùng PageDto để trả content, page, size, totalElements, totalPages, tránh để cấu trúc JSON phụ thuộc trực tiếp vào implementation Page của thư viện. Giao diện HTML vẫn có thể dùng Page trong model vì đó là chi tiết nội bộ của ứng dụng.

Lỗi thường gặp và lưu ý

• Phân trang hiển thị từ 1 nhưng tham số xử lý từ 0; đừng cộng/trừ ở cả Controller và template.
• Không nối q trực tiếp vào SQL; dùng cơ chế tham số của repository hoặc truy vấn được bind.

Ghi nhớ

Phân trang đúng cần dữ liệu đúng, URL giữ trạng thái và giới hạn truy vấn hợp lý, không chỉ có hai nút trước/tiếp.

Tài liệu đối chiếu

• Paging and Sorting