Vì sao ba bài trước chưa đủ
Ba bài trước cho bạn ba bản vá đúng: ownership trong WHERE, mặc định từ chối ở pipeline, DTO riêng cho input. Cả ba đều cục bộ — chúng sửa một endpoint hoặc một cấu hình. Câu hỏi của bài này là: khi quy tắc phức tạp hơn "chủ sở hữu", ba bản vá đó đi tới đâu?
Hãy để quy tắc lớn lên như nó lớn lên trong dự án thật:
- "Người dùng đọc được đơn của chính mình." → một mệnh đề
WHERE. Xong. - "Admin đọc được mọi đơn." →
WHERE ... || user.IsAdmin. Vẫn ổn. - "Support đọc được đơn của khách đang có ticket mở." → mệnh đề bắt đầu cần một
JOIN. - "Kế toán đọc được đơn đã hoàn tất, trong công ty mình, thuộc năm tài chính chưa đóng." → dừng lại.
Ở bước 4 có ba vấn đề, và chỉ một trong ba là về độ dài của câu truy vấn:
- Quy tắc đã bị nhân bản. Nó xuất hiện ở endpoint đọc, ở endpoint export, ở báo cáo, ở job gửi email. Bốn bản, và chúng sẽ lệch nhau.
- Không ai đọc được quy tắc. Nó nằm rải trong bốn biểu thức LINQ. Câu hỏi "ai đọc được đơn hàng?" không có chỗ nào để trả lời — kể cả cho chính bạn sáu tháng sau.
- Không ai kiểm được quy tắc. Muốn test "kế toán không đọc được đơn của công ty khác" thì phải test qua HTTP, bốn lần, cho bốn nơi.
Điểm quyết định tập trung là câu trả lời cho ba vấn đề đó — và cần nói rõ nó không phải câu trả lời cho vấn đề gì: nó không thay thế mệnh đề WHERE. Một hàm CanRead(user, order) trả về true vẫn cần truy vấn có điều kiện, nếu không bạn quay về lọc-sau-khi-fetch với mọi nhược điểm của nó.
Bình luận
Bình luận cần tài khoản đã hoàn thành ít nhất một bài học. Điều kiện đó là thứ giữ cho luồng thảo luận này còn đáng đọc: mỗi ý kiến gắn với một người có thể bị hỏi lại, và reputation tích luỹ theo thời gian.
Bạn vẫn đọc được toàn bộ bình luận dưới đây mà không cần tài khoản. Đăng nhập xong bạn sẽ quay lại đúng chỗ này, không phải đầu trang.
Đang tải bình luận…