chốt lại e thấy bác
4nh7i3m nói khá đúng cho các trường hợp normal, vậy xin mạn phép hỏi bác (và các bác khác nữa) mấy case mà các bác trên này có hỏi:
- xử lý ntn với gọi các service với nhau - có nên gọi không?
- với các lệnh Join thì đặt ở repository nào của table nào?
Trước tiên tui cảm ơn ông.
Nhưng tui chỉ nêu ý kiến thôi. Tui không bảo giờ nói cách của tui là đúng hay chính xác cả. Tui cũng chưa nói xấu ai bao giờ. Thích thì search post tôi mà xem nhưng thái độ nói chuyện của một số anh trong này phải nói là rất tệ. Chụp mũ, bẻ ý, đâm chọt cá nhân... nói chung là tệ (hay nói đúng hơn là hèn). Nên anh nào không thích tôi thì ignore tui mịa dùm cái. Còn ko nói để tôi ignore mấy anh.
Rồi về phần câu hỏi của bạn.
1. Circular Reference thì bạn hỏi thì tôi nói rõ hơn là mô hình tôi tổ chức có tới 5 lớp (chứ ko phải 3 lớp như thông thường).
Controller --> Service --> Session/Cache --> Repo --> Provider/IO.
Tạm bỏ qua cách gọi tên các lớp đi. Thì mô hình 5 lớp này tạm giải quyết được circular ref. Khi nào bị circular reference thì đưa function cần dùng (nhớ là function thôi nhé) xuống lớp nằm dưới.
Tức là ví dụ entity User sẽ có UserController, UserService, UserSession, UserRepo, UserProvider.
5 thằng sẽ phối hợp để đọc ghi dữ liệu và xử lý logic. Ví dụ, trong UserService nó có hàm KickUser cần dùng ở 1 service khác thì đưa nó xuống UserSession để dùng chung với Service khác.
Lưu ý: Nếu đưa hàm xuống 1 lớp mà lại lôi theo 1 đống khác xuống theo thì bạn coi lại design vì đó là dấu hiệu design của bạn bị lỗi.
Cái hay ở đây là lớp Session nó có thể chứa Business Logic mà vừa làm Cache luôn nên giảm tải cực lớn cho phần Repo bên dưới. Tương tự lớp Provider dành cho settings hay external content cố định.
2. Lệnh join thì thằng nào sở hữu Foreign key thì join ở thằng đó. Ví dụ UserTable có RoleId thì dùng join ở User để fetch Role. Câu này tôi ko chắc tôi có hiểu đúng ý bạn không?
( em đang làm là 1 service sinh ra quá nhiều repository khiến hệ thống rất khó maintain hic
Ví dụ: màn hình list user thì chỉ có 2 thông tin: username, email, màn hình user detail thì có full thông tin. Vậy sẽ cần xây dựng 2 model cho từng màn hình?
- phía client.
