thảo luận Vấn đề về separate Repository/Service/Controller

_Worker_of_MUFC_ đã nói:

Hi bạn,
Mô hình của bạn đưa ra thì đúng là thích hợp hơn so với mô hình cũ. Còn việc thuyết phục thì bạn cứ đem mấy cái examples của Spring MVC là các ông ấy im hết thôi mà.

Nhưng mô hình của bạn (cũng như nhiều người khác) thực ra cũng không phải là thích hợp lắm đâu. Để mình phân tích một vài điểm "chưa tương thích" nhé:

- Sự chồng chéo trong code: với mỗi controller, service, repo thì sẽ có sự chồng chéo lẫn nhau.
Eg: UserController sẽ phải có trong đó UserService, OrderService,... Xong rồi trong mỗi Service sẽ lại đẻ ra cả đống repo ở dưới. Tới lượt các controller khác cũng cần các services khác.
--> Sự chồng chéo trong code này một khi có bug (điều hiển nhiên) sẽ rất khó để sửa vì mỗi thằng lại liên quan tới cả đống thằng khác.

- Khó trong việc maintain: với mỗi function khi maintain, thêm/sửa các chức năng, dev sẽ phải tìm tất cả những thằng liên quan --> Việc miss reqs là chuyện rất dễ xảy ra.

Việc có 1 project structure ngon cũng cần nhiều exp và kĩ năng đấy.

Nhấp để mở rộng...

• Repo: mỗi table sẽ chỉ có tối đa 1 repo làm nhiệm vụ CRUD cho table đó. (xem nó như là lính canh của từng bảng, mình bảo m cập nhật giúp t cái này, xóa cái kia trong bảng, tìm... nhiệm vụ của nó chỉ có v, ko hơn ko kém).
• Service: Service nào cần CRUD vào bảng nào sẽ inject đến đúng Repo tương ứng.

• userService.login(loginPayload); input payload = output logged credentials (1)
• userService.getBasicInfo(); output = user logged dto; (2)

RPG29 đã nói:

Một trong những cách chia hợp lý và dễ áp dụng là dùng Kiến Trúc Củ Hành (Onion Architecture). Nó dễ tiếp cận hơn là Hexagonal Architecture hay Clean Architecture.

Core của ứng dụng là domain chứa Model, Entity, Repository Interface.
Layer ngay bên ngoài core là Application hoặc Service
Ngoài cùng là transportation layer chính là HTTP Controller, gRPC Controller, AMQP Handler, CLI, Test...

Các layer bên trong không biết không quan tâm các layer bên ngoài.

Chia đơn giản 3 layers vậy thôi, phức tạp hơn thì chia nhỏ hơn nữa tùy yêu cầu.

Nhấp để mở rộng...

soledad86 đã nói:

Vấn đề là bạn không hiểu cách vận hành của nó, cách bạn giải thích nó ko logic, ko clear.

Theo pattern như đã nói ở #1, các layers gồm:

• Repo: mỗi table sẽ chỉ có tối đa 1 repo làm nhiệm vụ CRUD cho table đó. (xem nó như là lính canh của từng bảng, mình bảo m cập nhật giúp t cái này, xóa cái kia trong bảng, tìm... nhiệm vụ của nó chỉ có v, ko hơn ko kém).
• Service: Service nào cần CRUD vào bảng nào sẽ inject đến đúng Repo tương ứng.

=> n-Service -> 1 repo
Example: ví dụ
1. ProductService: cần lưu thông tin vào table Product và table Storage (images path) khi đó cần inject ProductRepo và StorageRepo
2. FeedbackService tương tự cho table Feedback và table Storage (images path)
...
Do đó không có chuyện mỗi service đẻ ra một đống repo ở dưới.

* Func/Controller:
- API nào cần sử dụng đến service nào thì call service đó. Việc unitest, debug, maintain thì dựa theo
business trong service. Cái này cực dễ vì mỗi method call từ service đã rõ ràng từ input và output.

Tôi lấy ví dụ:
Trong UserController / API Login : có 2 actions chính.

• userService.login(loginPayload); input payload = output logged credentials (1)
• userService.getBasicInfo(); output = user logged dto; (2)

Do đó việc debug, unit-test là cực kì dễ dàng ... dựa vào (1)(2)...(x) để debug.
Và code theo pattern nào thì mấy ông cũng phải đảm bảo cái SOLID giùm chứ không thì có bn pattern cũng vậy.

Nhấp để mở rộng...

_Worker_of_MUFC_ đã nói:

Bạn suy nghĩ quá ngây thơ, điều này chứng tỏ rằng bạn không có quá nhiều kinh nghiệm về cái này. Để mình chỉ ra vài chỗ "chưa đúng" của bạn nhé.

1. Repo mà đơn giản tới mức chỉ có CRUD thì quẳng Service đi được rồi. Hay đơn giản hơn, giả sử có 1 query dạng join tables thì bạn để query đấy ở đâu?

2. Dù bạn phân chia có tốt tới ntn thì chắc chắn sẽ phải có trường hợp 1 Service đi kèm với N Repos, và 1 Controller đi kèm với N Service, chưa kể cái trò Service trong Service. Và một khi đã đụng tới vấn đề kiểu 1 - N thì việc chồng chéo code là chắc chắn xảy ra.

Còn việc bạn đưa ra 1 good example đâu có nghĩa là tất cả các case đều ok như thế? Gặp nhiều case tréo nghoe, đặt chỗ này thì lỡ cỡ, đặt chỗ kia cũng không ổn thì làm thế nào?

3. Bạn phải hiểu rằng việc phân chia project/code structure hợp lý là để áp dụng cho cả team. Có nghĩa là bạn làm đúng theo rule, nhưng người khác chưa chắc đã có thể áp dụng đúng rule ấy được. Nó phụ thuộc vào quá nhiều yếu tố. Vậy nên mình mới nói việc này cần cả về kĩ năng lẫn kinh nghiệm.

4. Cái SOLID là cái có quá nhiều người suốt ngày ra rả về nó, nhưng số người "hiểu" và "áp dụng" được vào code của mình (không cần 100%, khoảng > 80% là ok lắm rồi) lại không quá nhiều đâu.

Nhấp để mở rộng...

quandaso đã nói:

Chia lắm làm gì cho đau đầu nhỉ. Chính vì oop các bố đẻ ra lắm pattern quá nên thành ra ko thống nhất, code càng to càng rối rắm
bọn fp nó coi thường oop là vì thế. Chỉ phân chia thành các function thôi ko đc hay sao. Vẽ ra lắm thì sau này càng đau đầu về sau. Việc viết logic trong controller cũng chả sao cả, miễn là chia nhỏ thành các method mỗi method đặt tên cho đúng chức năng nó đảm nhận là đc

Nhấp để mở rộng...

katoshi đã nói:

Chung tôi bàn là bàn vụ kiến trúc và module hóa chứ nếu a áp thuần tuý cái anh vừa nêu trên thì tôi tuong tượng trong 1 file lẫn lộn 50+ hàm ( đặt tên đúng và rõ ràng nha) của 2 3 4 loại logic 1 chỗ thì đúng là thảm họa.

Việc chọn cấu trúc này ko liên quan OOOP hay FP j đâu, thằng nào cũng cần

Nhấp để mở rộng...

quandaso đã nói:

Ờ, thảm họa như nào vậy bạn? Nó chỉ thảm họa khi rơi vào tay 1 ông lead kém, không biết dẫn dắt team đi theo 1 thể thống nhất ( mà thực ra khi đã kém thì khi áp pattern vào thì nó sẽ ra 1 đống bùi nhùi, chỉ có đập đi làm lại). Chia function thôi cũng là nghệ thuật đấy!.
Tôi ví dụ đơn giản như là windows 32 API , hay linux kernel API nó toàn là 1 đống function đấy, bạn cũng chê nó là thảm họa đúng không?

Nhấp để mở rộng...

_Worker_of_MUFC_ đã nói:

1. Repo mà đơn giản tới mức chỉ có CRUD thì quẳng Service đi được rồi. Hay đơn giản hơn, giả sử có 1 query dạng join tables thì bạn để query đấy ở đâu?

Nhấp để mở rộng...

katoshi đã nói:

đọc kỹ lại giùm. đọc thôi mà cũng thọt chữ nữa hả ông? Mắt toét à ông thần.
thảm họa khi: 1 FILE có nhiều hàm 50+ func. lẫn lộn của 2 3 4 logic khác biệt chung 1 chỗ. Còn mã nguồn Win32 API nó có bị như tôi đã nói đâu mà nát.

Nhấp để mở rộng...

katoshi đã nói:

Cái 1 ban hơi nhầm.
Đúng là nó có thể đơn giản có thể cắt bỏ đc tầng services.
Nhưng mình khuyên là không nên. Vì có 1 thứ là code (style) consistency. Cấu trúc code của bạn tránh vụ ở nơi này làm kiểu nầy , ở nơi khác làm kiểu khác cho cùng 1 dạng vấn đề.

Nhấp để mở rộng...

phongkyanh đã nói:

Để ở repo được mà anh? Ông thớt bảo repo sẽ làm việc với entity (table) đấy thôi?

via theNEXTvoz for iPhone

Nhấp để mở rộng...

_Worker_of_MUFC_ đã nói:

Lập luận logic là hơi kém à nha.

Giờ có 2 bảng: User và Order --> Có 2 repo UserRepo và OrderRepo.
Chắc chắn có 1 query liên quan tới cả User và Order, cứ gọi nó là 1 join query nhé.
Câu query này bảo đặt ở đâu cũng được phải ko nhỉ? Giờ đặt tạm ở UserRepo nhé.
Xong rồi trong OrderService cũng cần câu query ấy (logic rất thường gặp phải không nào?) thì lại phải invoke thằng UserRepo à? Thế thì làm sao còn đảm bảo tính 1 - 1 nữa

Nhấp để mở rộng...