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

Niels Henrik Abel said:

Ai là người quyết định structure? nếu có lead thì để lead quyết đi.
Bên tớ đang làm theo kiểu này:
View attachment 303787

Note hay nè: https://learning-notes.mistermichee...rchitectures/package-by-feature-or-component/

Angelino said:

Có lẽ là project đơn giản nên họ làm tắt, bỏ qua service layer cho nhanh. Cái này hiểu được mà.

duyquang6 said:

kiếm bài hexagonal architect của netflix mà đọc

Nipin said:

tuỳ scope dự án tới đâu, bao nhiêu người cùng làm (tính riêng backend) chứ làm gì có silver bullet.

best practice của công ty 1000 nhân viên nó khác với công ty 10 nhân viên nhiều (dù là kể cả ở công ty lớn một team cũng chỉ bấy nhiêu người).

ờ kể cả ngôn ngữ nữa, có ngôn ngữ này dễ làm với cái pattern này hơn ngôn ngữ khác dễ làm với cái pattern khác hơn, làm đíu gì có cái "ngôn ngữ nào cũng làm được". mấy thằng nói câu ấy tôi thấy toàn là greenhorn.

thiensau ver1 said:

Bên mình cũng y vậy, có điều chỗ service code nhiều quá, nên mình đẻ ra thêm 2 layer nữa, là validator để validate và business để handle các logic, mà thấy trong service vẫn còn xử lý nhiều, chắc do chia ngu quá

Fire Of Heart said:

Cho mình hỏi :

Đây là bạn đang nói việc thiết kế cho 1 hệ thống từ đầu hay là nó đã có sẵn và bạn đang đề nghị thiết kế lại theo 1 hướng khác ?

Còn về phương án thiết kế của bạn thế cũng là khá ổn và rạch ròi. Đây là 1 pattern cũng phổ biến.

Tuy nhiên nếu nó đã có sẵn và việc đập đi xây lại nhiều khi tốn công mà ng ta ko muốn nhúng tay vào. Còn việc review code bị soi kỹ hơn thì mình tạm đoán là việc raise ý kiến của bạn khiến bị mọi người trong team ko ưa chăng ?

• Bạn đề nghị làm cách này là nói suông thôi hay có một buổi trình bày bằng slide đàng hoàng? Có viết document hay không?
• Bạn có thử viết một đoạn code nhỏ nhỏ (càng gần với context của công ty càng tốt) mà người ta đọc vào thấy rõ được sự khác biệt giữa hai cách làm không?

soledad86 said:

Bác validate những gì trong đó?...nếu nhiều quá thì separate XService, XValidatorService, XAnotherService,...để tiện cho sau dễ bundle module...chia vậy thấy cũng ổn mà

thiensau ver1 said:

à mình chia như bác nói đó, CustomerValidator chẳng hạn, trong đó có validate create customer request, validate date of birth ..., kiểu vậy đó bác.

À mà bên mình từ Service không gọi xuống các repo khác như bên bác, mà gọi qua các Service khác.

2. Service: sẽ chỉ làm việc với Repo và 3rd nếu có để cung cấp n-method cho 1 service nào đó. 1 Service có thể inject n-dependencies bao gồm các repo.
(ví dụ: AuthUserService sẽ làm việc với UserRepo, UserPermissionRepo, CryptoXXX (3rd) để cung cấp các method như RegisterUser, LoginUser ... vvv)

Bên mình thì AuthUserService sẽ làm việc với UserService, UserPermissionService .., kiểu vậy

thiensau ver1 said:

à mình chia như bác nói đó, CustomerValidator chẳng hạn, trong đó có validate create customer request, validate date of birth ..., kiểu vậy đó bác.

À mà bên mình từ Service không gọi xuống các repo khác như bên bác, mà gọi qua các Service khác.

2. Service: sẽ chỉ làm việc với Repo và 3rd nếu có để cung cấp n-method cho 1 service nào đó. 1 Service có thể inject n-dependencies bao gồm các repo.
(ví dụ: AuthUserService sẽ làm việc với UserRepo, UserPermissionRepo, CryptoXXX (3rd) để cung cấp các method như RegisterUser, LoginUser ... vvv)

Bên mình thì AuthUserService sẽ làm việc với UserService, UserPermissionService .., kiểu vậy

Reishou said:

Ý kiến thì một số thím phía trên có trình bày rồi. Mình chỉ share resource sau:
https://edwardthienhoang.wordpress.com/software-architecture/

Nó có trình bày từ thời đầu của software architect, thời của 1 layer - 2 layer, rồi đến MVC, MVVC... rồi qua Onion, DDD...

soledad86 said:

service inject lẫn nhau đợt trước mình cũng có làm, nhưng trong DI cũng nên hạn chế dùng vì có khả năng xảy ra "circular dependency"

quangdv.xf said:

Có thể do cách trình bày của bạn chưa thuyết phục.

• Bạn đề nghị làm cách này là nói suông thôi hay có một buổi trình bày bằng slide đàng hoàng? Có viết document hay không?
• Bạn có thử viết một đoạn code nhỏ nhỏ (càng gần với context của công ty càng tốt) mà người ta đọc vào thấy rõ được sự khác biệt giữa hai cách làm không?

Cứ pick ra một đoạn code hiện tại và viết lại theo cách bạn muốn hướng mọi người. Xong book meeting present giới thiệu cách mới. Nói ngắn gọn đảm bảo người nghe hiểu. Xong cho mọi người ý kiến thảo luận blah blah... Còn làm hết rồi mà vẫn không được thì cũng kệ thôi.

soledad86 said:

bác muốn nhắn nhủ điều gì ?

soledad86 said:

Em làm việc tại công ty X được 3 năm, ae toàn senior.
Tại 1 công ty Y em mới vào, tình hình là em và ae có một số ý kiến bất đồng trong việc phân tách các layers gồm Repository / Service và Controller/Serverless Func

Các bác lâu năm exp cho em hướng xử lý trong case này với.

Sơ sơ tình hình là với vấn đề trên, em sẽ chia ra các layer với reponsibility khác nhau.
1. Repo: sẽ làm việc với SQL và map vào entity. thực hiện các tác vụ với DB của 1 table nào đó
(ví dụ: UserRepo sẽ làm việc với UserEntity và thực hiện các thao tác thêm xóa sửa đối với bảng User)
2. Service: sẽ chỉ làm việc với Repo và 3rd nếu có để cung cấp n-method cho 1 service nào đó. 1 Service có thể inject n-dependencies bao gồm các repo.
(ví dụ: AuthUserService sẽ làm việc với UserRepo, UserPermissionRepo, CryptoXXX (3rd) để cung cấp các method như RegisterUser, LoginUser ... vvv)
3. Controller/Func: sẽ chỉ làm việc với Service để thực thi các phương thức
(ví dụ: AuthController sẽ có API Login => trong đó sẽ call 2 action là AuthService.login và AuthService.getBasicInfo ... vvv)

Theo quan điểm của em thì nó là basic và flexible.. theo pattern này thì có thể apply cho bất kỳ ngôn ngữ nào.
Em có research thì cũng thấy các ref pattern giống giống cách của em .
https://exceptionnotfound.net/the-r...n-with-dependency-injection-and-asp-net-core/

Vấn đề là như vậy, em cũng trình bày với ae trong cty nhưng 4-10 người role cao hơn em ko đồng ý (em ko bàn tới skill của họ nhưng nếu họ giải thích được lí do chính đáng thì em ko comment), còn lại mấy ae dưới ko ý kiến -> 9/10.
Họ cho rằng controller nên gọi thẳng repository, còn service chỉ dùng cho 3rd.
logic nên implement luôn trong controller -> em có phản biện rằng có 1 số case cần dùng lại logic này thì ntn? thì ko trả lời được

Và do ý chỉ 1/10 nên cuối cùng thì ý kiến của em bị reject. Khi review code cũng bi soi khá nặng nề, hiuhiu
Các bác đã gặp hay có hướng xử lý nào cho trường hợp giống em không ?

• Ví dụ có ProductController và TProductController ( thrift ) đều gọi vô ProductService nhưng 1 cái cho http dữ liệu trả về dạng JSON, 1 cái cho Thrift api.
• Sau này đẻ thêm 1 đầu controller cần data trả về xài Protobuf thì thêm controlller và để logic convert response . Còn service thì ko đổi j

soledad86 said:

Em làm việc tại công ty X được 3 năm, ae toàn senior.
Tại 1 công ty Y em mới vào, tình hình là em và ae có một số ý kiến bất đồng trong việc phân tách các layers gồm Repository / Service và Controller/Serverless Func

Các bác lâu năm exp cho em hướng xử lý trong case này với.

Sơ sơ tình hình là với vấn đề trên, em sẽ chia ra các layer với reponsibility khác nhau.
1. Repo: sẽ làm việc với SQL và map vào entity. thực hiện các tác vụ với DB của 1 table nào đó
(ví dụ: UserRepo sẽ làm việc với UserEntity và thực hiện các thao tác thêm xóa sửa đối với bảng User)
2. Service: sẽ chỉ làm việc với Repo và 3rd nếu có để cung cấp n-method cho 1 service nào đó. 1 Service có thể inject n-dependencies bao gồm các repo.
(ví dụ: AuthUserService sẽ làm việc với UserRepo, UserPermissionRepo, CryptoXXX (3rd) để cung cấp các method như RegisterUser, LoginUser ... vvv)
3. Controller/Func: sẽ chỉ làm việc với Service để thực thi các phương thức
(ví dụ: AuthController sẽ có API Login => trong đó sẽ call 2 action là AuthService.login và AuthService.getBasicInfo ... vvv)

Theo quan điểm của em thì nó là basic và flexible.. theo pattern này thì có thể apply cho bất kỳ ngôn ngữ nào.
Em có research thì cũng thấy các ref pattern giống giống cách của em .
https://exceptionnotfound.net/the-r...n-with-dependency-injection-and-asp-net-core/

Vấn đề là như vậy, em cũng trình bày với ae trong cty nhưng 4-10 người role cao hơn em ko đồng ý (em ko bàn tới skill của họ nhưng nếu họ giải thích được lí do chính đáng thì em ko comment), còn lại mấy ae dưới ko ý kiến -> 9/10.
Họ cho rằng controller nên gọi thẳng repository, còn service chỉ dùng cho 3rd.
logic nên implement luôn trong controller -> em có phản biện rằng có 1 số case cần dùng lại logic này thì ntn? thì ko trả lời được

Và do ý chỉ 1/10 nên cuối cùng thì ý kiến của em bị reject. Khi review code cũng bi soi khá nặng nề, hiuhiu
Các bác đã gặp hay có hướng xử lý nào cho trường hợp giống em không ?

buzbum said:

Chỗ em mấy ông code xử lý hết trong controller, đẻ ra tầng service chỉ làm mỗi việc là return từ repo, nhiều xử lý giống nhau cứ nghe ông lead clone ra là xong. -_- nhìn rác vcc.

katoshi said:

Điều thím nói nó rác thì hơi định kiến.

Điều thím nói xảy ra khi logic rất đơn giản, dạng simple CURD. Nhưng đời nào đơn giản thế.

memay said:

Bên mình chia code theo feature, bạn đọc cách chia thư mục cho dự án trên mạng thì biết. Nên chia theo feature (như user, product) không theo role (repository, entity).

Code dùng chung cho vô thư mục services hay utils.
Mỗi feature thì có thể sử dụng cấu trúc thư mục khác nhau cũng được, nó có một số model(entity) của riêng mình và có thể dùng đọc model(entity) của feature khác.

Feture này ghi dữ liệu phần model của feature khác bằng cách gửi message qua message queue hoặc feature có public function để gọi, hoặc cũng có thể gọi qua rest api.

Logic của feature nào thì feature đó xử lý.

Quan trọng nhất là tách feature ra với giữ lại cái function ghi dữ liệu cho feature khác xài. Khi refactor hay upgrade tính năng thì chỉ giữ lại public function này là được.

Bạn chia theo role kiểu kia thì không biết cái sevice nào phụ thuộc cái nào. Nếu sửa 1 cái service thì không biết cái khác có ảnh hưởng không.

thiensau ver1 said:

à mình chia như bác nói đó, CustomerValidator chẳng hạn, trong đó có validate create customer request, validate date of birth ..., kiểu vậy đó bác.

À mà bên mình từ Service không gọi xuống các repo khác như bên bác, mà gọi qua các Service khác.

2. Service: sẽ chỉ làm việc với Repo và 3rd nếu có để cung cấp n-method cho 1 service nào đó. 1 Service có thể inject n-dependencies bao gồm các repo.
(ví dụ: AuthUserService sẽ làm việc với UserRepo, UserPermissionRepo, CryptoXXX (3rd) để cung cấp các method như RegisterUser, LoginUser ... vvv)

Bên mình thì AuthUserService sẽ làm việc với UserService, UserPermissionService .., kiểu vậy

Khang.Hy.Gia.222 said:

nghe nói toàn lý thuyết. thế ông trình bày hay thế sao ae k theo cách của ông? tôi muốn nghe ý kiến trong buổi đó tại sao ng ta bác đi

pthuy said:

Theo mình số đông sẽ làm theo cách của thím thớt. Implement logic và gọi thẳng Repo trong controller thực sực không hay, như thớt nói về reuseable chẳng hạn, cấu trúc code sẽ tách biệt rành mạch, ví dụ ngày đẹp trời nào đó services nó trở nên phình to quá và có nhiều function hay ho cần dùng cho project khác thì bác có thể tách hẳn cục service ra 1 project xem như 1 dependency. Hơn nữa controller sẽ trở nên hỗn độn và mất đi ý nghĩa thực sự của nó. Các bác ở cty reject ý của thím chắc là code quen tay, không muốn thay đổi, code ở controller có gì cứ vào đó tìm thay vì chạy tới các chỗ khác nhau

_Worker_of_MUFC_ said:

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.

• 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 said:

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.

soledad86 said:

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.

_Worker_of_MUFC_ said:

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.

quandaso said:

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

katoshi said:

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

quandaso said:

Ờ, 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?

_Worker_of_MUFC_ said:

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?

katoshi said:

đọ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.

katoshi said:

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 đề.

phongkyanh said:

Để ở 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

_Worker_of_MUFC_ said:

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

quandaso said:

1 file có 50+ function thôi mà bạn đã sợ à bạn. thế mời bạn xem redis source code với git source code.
https://github.com/redis/redis/blob/unstable/src/server.c
https://github.com/git/git/blob/master/diff.c
Ngoài ra anh em có thể xem root source tree của git và redis nó chia cực đơn giản
p/s: Hình như hồi đầu redis còn đút tất cả source code vào 1 file luôn cơ
Nói thật source của 2 ông trên mới có 6k LOC 1 file, tôi còn maintain 1 file source controller có 12k LOC cơ. Nhưng hệ thống nó vẫn ngon lành chả vấn đề gì căn bản mỗi hàm của nó chia ra cực kì clear, đọc tên hàm đã hiểu chưa cần đến comment

KBGLTB said:

Nếu vậy thì giải quyết vấn đề này như thế nào vậy bác?

tdat00 said:

Còn ông nào bảo source code gì 6k Sloc kia chắc là thánh rồi, tôi không hiểu merge code kiểu gì.

Sent from Samsung SM-G973F using vozFApp

memay said:

Những phần mềm phức tạp lại chia đơn giản. Còn mấy cái như thớt thì chia phức tạp. Mà chức năng nào cũng chia theo repository, model, entity, service, controller các thứ. Cũng tùy vì không phải phần mềm web nào cũng làm vậy và cách làm đó lại khá cứng nhắc.

memay said:

Những phần mềm phức tạp lại chia đơn giản. Còn mấy cái như thớt thì chia phức tạp. Mà chức năng nào cũng chia theo repository, model, entity, service, controller các thứ. Cũng tùy vì không phải phần mềm web nào cũng làm vậy và cách làm đó lại khá cứng nhắc.

quandaso said:

Thì 1 ông cầm master thôi mà. Conflict (nếu có) cũng đâu có khó xử lí đâu. Mà tôi thấy merge 1 file đỡ đau đầu so với merge một đống file chứ

_Worker_of_MUFC_ said:

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

KBGLTB said:

Nếu vậy thì giải quyết vấn đề này như thế nào vậy bác?

tdat00 said:

Tách nhỏ ra nhiều file mới đỡ conflict ông ơi. Gom chung vào 1 file rồi cái ông cầm master kia suốt ngày đi merge code hả.

Sent from Samsung SM-G973F using vozFApp

quandaso said:

Ông dùng pull/merge request bao giờ chưa. Ông master chỉ review rồi merge vào thôi mà có phải fix gì đâu. Ông mà phải fix conflict là ông dev fix bug kia ấy chứ

tdat00 said:

Thôi, có vẻ ông ít gặp vụ code conflict rồi. Nó không đơn giản như ông nghĩ đâu, mà tôi cũng không biết giải thích sao cho dễ hiểu. Khi nào gặp ông sẽ ngộ ra.

Sent from Samsung SM-G973F using vozFApp

tdat00 said:

Tách nhỏ ra nhiều file mới đỡ conflict ông ơi. Gom chung vào 1 file rồi cái ông cầm master kia suốt ngày đi merge code hả.

Sent from Samsung SM-G973F using vozFApp

quandaso said:

Hờ tớ 10 năm exp, hiện đang lead team 7 người và quản lí 15 cái source base của 1 start up nhé. Bạn muốn chia sẻ kinh nghiệm gì với tớ cứ chia sẻ lên đây thôi Việc merge source code của member trong team một ngày t phải làm không dưới 10 lần đâu

Nipin said:

nghe nói là bạn làm php, php mà quản lý tốt như thế cũng đáng nể đấy

soledad86 said:

Em làm việc tại công ty X được 3 năm, ae toàn senior.
Tại 1 công ty Y em mới vào, tình hình là em và ae có một số ý kiến bất đồng trong việc phân tách các layers gồm Repository / Service và Controller/Serverless Func

Các bác lâu năm exp cho em hướng xử lý trong case này với.

Sơ sơ tình hình là với vấn đề trên, em sẽ chia ra các layer với reponsibility khác nhau.
1. Repo: sẽ làm việc với SQL và map vào entity. thực hiện các tác vụ với DB của 1 table nào đó
(ví dụ: UserRepo sẽ làm việc với UserEntity và thực hiện các thao tác thêm xóa sửa đối với bảng User)
2. Service: sẽ chỉ làm việc với Repo và 3rd nếu có để cung cấp n-method cho 1 service nào đó. 1 Service có thể inject n-dependencies bao gồm các repo.
(ví dụ: AuthUserService sẽ làm việc với UserRepo, UserPermissionRepo, CryptoXXX (3rd) để cung cấp các method như RegisterUser, LoginUser ... vvv)
3. Controller/Func: sẽ chỉ làm việc với Service để thực thi các phương thức
(ví dụ: AuthController sẽ có API Login => trong đó sẽ call 2 action là AuthService.login và AuthService.getBasicInfo ... vvv)

Theo quan điểm của em thì nó là basic và flexible.. theo pattern này thì có thể apply cho bất kỳ ngôn ngữ nào.
Em có research thì cũng thấy các ref pattern giống giống cách của em .
https://exceptionnotfound.net/the-r...n-with-dependency-injection-and-asp-net-core/

Vấn đề là như vậy, em cũng trình bày với ae trong cty nhưng 4-10 người role cao hơn em ko đồng ý (em ko bàn tới skill của họ nhưng nếu họ giải thích được lí do chính đáng thì em ko comment), còn lại mấy ae dưới ko ý kiến -> 9/10.
Họ cho rằng controller nên gọi thẳng repository, còn service chỉ dùng cho 3rd.
logic nên implement luôn trong controller -> em có phản biện rằng có 1 số case cần dùng lại logic này thì ntn? thì ko trả lời được

Và do ý chỉ 1/10 nên cuối cùng thì ý kiến của em bị reject. Khi review code cũng bi soi khá nặng nề, hiuhiu
Các bác đã gặp hay có hướng xử lý nào cho trường hợp giống em không ?

• Nếu controller gọi thẳng repo thì các anh "hát mẹ cốt" là bắt buộc phải lấy data từ db lên rồi. Sau này (giả sử) db của anh không còn cái entity đấy vì tách ra thành micro-service khác rồi, thì anh lại phải sửa lại code (+test) cho cái controller đấy. Còn nếu thay đổi implementation của repo để gọi đến 3rd party API thay vì gọi đến db (để tránh sửa code và test ở controller) thì lại vi phạm convention đặt ra từ đầu (repo xử lý table) gây hoang mang cho người đến sau
• Nếu controller gọi service thì ở tầng controller nó chỉ quan tâm là cái service đấy nó cung cấp cho tao cái API đấy (bỏ input vào là ra expected output) còn nó làm mẹ gì ở dưới kệ nó, nó có gọi đến repo để lấy data trực tiếp từ db hay gọi đến 3rd party API kệ nó => nếu đổi cách lấy data (chẳng hạn) thì anh chỉ cần thay mẹ cái implementation mới (+test mới) cho thằng service đấy thôi không phải thay đổi code (hay test) ở tầng controller.

quandaso said:

Làm start up thực ra mỗi thứ 1 tí. Devops,front end,backend thậm chí có cả bê máy chủ lên viettel idc để lắp đặt nữa cơ
Nói về php thì ông nào chê thì chê chứ t thấy vẫn ok, quan trọng là nó giải quyết đc bài toán thôi. Php hồi xưa thì lởm chứ version 7 có static type là scale ngon lành rồi

quandaso said:

Thì 1 ông cầm master thôi mà. Conflict (nếu có) cũng đâu có khó xử lí đâu. Mà tôi thấy merge 1 file đỡ đau đầu so với merge một đống file chứ

quandaso said:

Ông dùng pull/merge request bao giờ chưa. Ông master chỉ review rồi merge vào thôi mà có phải fix gì đâu. Ông mà phải fix conflict là ông dev fix bug kia ấy chứ

quandaso said:

Hờ tớ 10 năm exp, hiện đang lead team 7 người và quản lí 15 cái source base của 1 start up nhé. Bạn muốn chia sẻ kinh nghiệm gì với tớ cứ chia sẻ lên đây thôi Việc merge source code của member trong team một ngày t phải làm không dưới 10 lần đâu

4nh7i3m said:

Ý kiến của mình là nên làm như chủ xị. Tức là Controller gọi service. Ko build logic trong controller.
Lý do: Để unit test. Để reusable. Để dependency injection.

Cái thứ 2 là controller có được phép gọi thẳng repository ko? Câu trả lời là có và không.

Nếu repo có hàm cung cấp đúng dữ liệu cần thì ko cần qua service vì như vậy sẽ xảy ra function proxy ( function wrapper). Đó là lý thuyết (có) Nhưng cái này trong thực tế khó có trường hợp vậy (không)

Lý do: Repo thường là trả về full entity mà controller nó chỉ cần một phần trong đó thôi nên cần có service để bỏ bớt hoặc format lại dữ liệu. Cho nên thưc tế controller gọi thẳng repo là cực hiếm.

phongkyanh said:

Tại vì anh không chia nhỏ file ra nên mới phải suốt ngày đi resolve conflicts thì có
Anh phải nghĩ là "không nên để xảy ra việc conflict" (risk0 gần bằng 0) thay vì "xử lý việc conflict không khó" (risk1 > risk0) chứ

thiensau ver1 said:

đúng rồi đó bác, nó đi inject circular luôn rồi

tomoco said:

repo trả về full entity thì code bác chưa tối ưu rồi, muốn lấy gì select cái đó thôi chứ

• Case 1: Tôi cần thông tin sau khi oauth chỉ gồm name và email.
• Case 2: Tôi cần thông tin cho Report cần name và personal id.
• Case 3: Tôi cần thông tin cho Salary bao gồm name, personal id và salary.
• Case N:...

quandaso said:

Anh phải phân biệt đc merge source code và resolve conflict chứ. Merge source thì ông lead nào chả phải làm hàng ngày )

phongkyanh said:

Tại vì anh không bắt chia nhỏ file ra nên dev mới phải suốt ngày đi resolve conflicts thì có

Anh phải nghĩ là "không nên để xảy ra việc conflict" (risk0 gần bằng 0) thay vì "xử lý việc conflict không khó" (risk1 > risk0) chứ

quandaso said:

Mà ông đừng hiểu nhầm tôi ko chia nhỏ file
Cái tôi lấy chỉ là ví dụ của cái dự án to đùng mà cấu trúc của nó vẫn đơn giản 1 featured/file thôi. Quản cái git thì muốn ko conflict thì ông phải biết cách chia feature cho team.

quandaso said:

Mà nếu có bị thì tôi cũng đâu phải là thằng đi resolve đâu mà ông dev phải resolve rồi update lại cái mergen request.

4nh7i3m said:

Giờ ví dụ như vầy. UserRepo. GetUserById.

• Case 1: Tôi cần thông tin sau khi oauth chỉ gồm name và email.
• Case 2: Tôi cần thông tin cho Report cần name và personal id.
• Case 3: Tôi cần thông tin cho Salary bao gồm name, personal id và salary.
• Case N:...

Thế là tôi phải viết N cái function để cần gì lấy đó thôi à? Thế anh tối ưu cho tôi trong trường hợp này tôi nên làm thế nào?

tomoco said:

có nhiều cách để làm, nhưng rõ ràng lấy full data của table ra là ko tối ưu mà nhỉ?
giả sử bảng nó có lưu 1 trường text dài kiểu html bác cũng lôi ra nghe ko cần thiết lắm nhỉ

tomoco said:

có nhiều cách để làm, nhưng rõ ràng lấy full data của table ra là ko tối ưu mà nhỉ?
giả sử bảng nó có lưu 1 trường text dài kiểu html bác cũng lôi ra nghe ko cần thiết lắm nhỉ

phongkyanh said:

Xin lỗi tôi nói thiếu.



Anh không vứt toàn bộ feature vào 1file là tôi mừng cho dev của anh

Còn tôi phân tích dựa trên cái ví dụ của anh nhé. Anh cứ tưởng tượng là có N ông dev cùng làm 1 feature/1 file. Nếu dev1 có commit1 thêm func1 vào cuối file, dev2 commit2 func2 cũng cuối file,... devN commitN funcN cũng cuối file. Thế có phải là sẽ có N-1 lần resolve conflicts không?

Đấy chỉ là mới nói chuyện bị conflict có 1 chỗ đấy nhé. Còn nếu có tầm X chỗ conflicts (càng nhiều người làm cùng 1 file + commit sửa nhiều chỗ trong file thì X càng dễ lớn) thì ông dev nào non có mà nhoè mẹ mắt

=> lại gọi lead hoặc tham khảo với team để resolve => tốn thời gian + risk
Nếu code scripting language mà không phải kiểu typesafe thì conflict lại càng đáng sợ

Resolve conflicts là việc của dev, nhưng take risk lại là việc của anh

=> tốt nhất là " không nên để xảy ra việc conflict" hoặc để X thật nhỏ bằng cách chia nhỏ file ra

quandaso said:

Ờ, 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?

quangdv.xf said:

Chẳng phải nếu FP rơi vào tay leader kém, áp dụng không đúng cách, thì cũng là thảm họa hay sao? (cần một người lead nghệ thuật để có thể chia function)

Mình cũng có thể nói ngược lại là để leader xịn thì áp dụng OOP pattern nào cũng thành công. Nhưng mà design pattern sinh ra là để giải quyết phần lớn những vấn đề chung thường gặp. Vậy không tránh được sẽ bị thiếu sót những vấn đề cụ thể. Design pattern mà cần một leader tài năng hay một team tài năng để áp dụng thì nó không còn là pattern nữa rồi. Nó sinh ra để cho những người kém tài năng như mình vẫn xài được nè.

quandaso said:

Một feature của git:diff dù rất to cũng chả cần đến 2 ông dev làm cùng lúc

phongkyanh said:

Đấy là anh nghĩ vậy thôi Tại sao anh không nghĩ đến việc sẽ có một repo khác handle những câu query kiểu liên quan đến cả 2 bảng user và order nhỉ. Ví dụ như UserOrdersJoinedRepo chẳng hạn (ví dụ nên bỏ qua tính đúng đắn của tên class đi nhé ). Vẫn đảm bảo"repo xử lý table", vừa đảm bảo luôn cả single responsibility nhé .
Còn cái cách bố trí câu query theo "lập luận logic" của anh nó có thuật ngữ gọi là "circular dependency" đấy

Đã nói ở trên nhé

phongkyanh said:

Thế là anh chưa gặp feature đủ to để nhiều dev cùng làm 1 lúc rồi
Thôi dừng lại đây đi. Tôi với anh đi lạc đề quá rồi

_Worker_of_MUFC_ said:

Hic, bạn thực sự có vấn đề trong việc tư duy logic.

Ngay từ đầu bạn chủ thớt đã cố gắng đưa vấn đề về việc đơn giản hoá, tránh việc 1 Service sẽ sinh ra nhiều repo. Giờ mới chỉ có 1 câu query join mà bạn sinh ra tới 3 repo class để handle. Thử tưởng tượng với business logic phức tạp thì vục mặt vào đống repo kia có mà chết à?

phongkyanh said:

Đấy là anh nghĩ vậy thôi Tại sao anh không nghĩ đến việc sẽ có một repo khác handle những câu query kiểu liên quan đến cả 2 bảng user và order nhỉ. Ví dụ như UserOrdersJoinedRepo chẳng hạn (ví dụ nên bỏ qua tính đúng đắn của tên class đi nhé ). Vẫn đảm bảo"repo xử lý table", vừa đảm bảo luôn cả single responsibility nhé .
Còn cái cách bố trí câu query theo "lập luận logic" của anh nó có thuật ngữ gọi là "circular dependency" đấy

Đã nói ở trên nhé

4nh7i3m said:

Lý do: Repo thường là trả về full entity mà controller nó chỉ cần một phần trong đó thôi nên cần có service để bỏ bớt hoặc format lại dữ liệu. Cho nên thưc tế controller gọi thẳng repo là cực hiếm.

4nh7i3m said:

Tối ưu là khi anh thay cả hệ thống database từ local lên cloud hay thậm chí đổi qua thằng database khác thì anh chỉ việc thay cái config hay đổi cái library implementation của repo là xong chứ không phải là ngưng cả hệ thống lại chờ Team Dev.

ChiNhaKhoa said:

con dự án công ty em cũng chia layer giống thím thớt đề cập, controller thì gọi tới service, service thì gọi các repo, thậm chí gọi cả service khác (chính em khi code thêm feature đã bắt trước inject thêm service và dính circular dependency

)
Tuy nhiên có một phần em thấy rất khó hiểu, đó là việc xử lý logic lại đấy cho thằng repo và controller là chủ yếu, những file controller hay repo 6k loc là chuyện rất bình thường, service layer thì đa số chỉ return repo.
Controller thì phải xử lý nhiều logic để tạo viewbag và viewmodel, còn tất cả các businesse logic đều xử lý trong Repo, đa phần là phải dùng những câu query join đến 4 5 tables (10 thằng thì có 7 thằng phải dùng query lên tới cả trang, còn lại là crud).
Em thắc mắc là nếu như business logic cần dùng đến nhiều query như thế, theo lý thuyết bác trên có nói thì repos chỉ crud và trả về full entity, thì chắc chắn code trong service sẽ bị phình cực to (thay vì chỏ dùng 1 câu query khoảng 50 loc thì phải viết 1 service 200 loc để đáp ứng nhu cầu tương tự). Như vậy có phải code bên em không clean, hay là do trên thực tế project phực tạp việc apply pattern 1 cách clean là việc khó khá thi ạ

gaveezy said:

Service gọi Service khác theo mình là hợp lý hơn việc nhét nhiều Repo vào Service vì nó sẽ làm cho việc sở hữu data bị chồng chéo. Bù lại phần Interface của Service phải được thiết kế tốt để tránh việc phải thay đổi để đáp ứng thay đổi của Business Logic.
Tổ chức theo kiểu này thì sau này chuyển sang microservices cũng dễ dàng hơn, chỉ cần implement một Service khác theo interface có sẵn nhưng bên dưới sẽ gọi Service bên ngoài.

khunglongtim3 said:

Các anh toàn đề xuất bỏ service, theo tôi bỏ repo là hợp ní, model service là quá đủ.
Ai phản bác cho xin lí do cái repo càn tồn tại là gì.

soledad86 said:

Với mình thằng sếp từng bộ phận (x-controller)...nó sẽ sai thằng đệ tử thân tín (x-service) tìm cho nó các đối tác kinh doanh ... Khi đó thằng đệ tử thân tín (x-service) sẽ sai thằng em (x-repo) tìm cho nó các đối tác nội địa (internal) và thằng em khác (x-3rd-service) tìm các đối tác nước ngoài. Do đó thằng x-repo cần tồn tại để làm nhiệm vụ cho thằng x-service...=> cơ cấu nhiệm vụ được cấu trúc trên xuống, thằng sếp chỉ quan tâm và yêu cầu từ thằng em gần nhất...khi đó suy xét tội cũng rõ ràng hơn.

khunglongtim3 said:

Thằng repo chả để làm gì chỉ rối thêm. Tôi gọi thẳng model luôn.

soledad86 said:

Mới v mà đã rối thì làm ăn gì nữa bác. Trong 3 layers, thằng repo như DAO..giao tiếp với DB. Thằng service như BUS...BUS thì ko được, ko nên giao tiếp với DB.
Vì nếu bác code như thế thì bác dường như là một anh thợ code không hơn không kém.
Mỗi ông mỗi nhiệm vụ...nếu một ông có từ 2 nhiệm vụ trở lên thì nên xem lại.

khunglongtim3 said:

Tôi giao tiếp qua model mà. Repo cũng chỉ là wrap model lại thôi. Nhiều orm đã full chức năng rồi, thêm repo lại đi viết lại chả để làm gì.
Có Orm lại còn dùng Dao nữa rảnh thật.
Tôi đảm bảo bạn sẽ phải viết nhiều hàm giống nhau ở cả service và repo như 1 bác ở page 2 gọi là proxy function.

• https://dzone.com/articles/repository-pattern-done-right

Update to address another answer​

N.V.T said:

Rách việc, dự án nó code thế nào thì cứ để vậy đi. Thằng dev thì cứ làm theo những gì thằng lead bảo, hết giờ thì về. Bao giờ mày lên lead thì mày sẽ hiểu cảm giác mấy nói mà mấy thằng dev đéo nghe nó cay thế nào.

Code thế nào cũng được, miễn là nó chạy đúng. Refactor lại là 1 câu chuyện khác.

Mã nguồn chỉ là phù du, chạy đúng mới là vĩnh cửu.

an21345 said:

công ty phần mềm
mã nguồn là thứ quan trọng nhất
mà nói thế này thì tội nghiệp cho công ty đó thật

N.V.T said:

Rách việc, dự án nó code thế nào thì cứ để vậy đi. Thằng dev thì cứ làm theo những gì thằng lead bảo, hết giờ thì về. Bao giờ mày lên lead thì mày sẽ hiểu cảm giác mấy nói mà mấy thằng dev đéo nghe nó cay thế nào.

Code thế nào cũng được, miễn là nó chạy đúng. Refactor lại là 1 câu chuyện khác.

Mã nguồn chỉ là phù du, chạy đúng mới là vĩnh cửu.

soledad86 said:

Xin lỗi anh đây (ko bàn đến thâm niên, kinh nghiệm làm leader bn năm), cho em xin phản biện một số ý sau đây:
1. "dự án nó code thế nào thì cứ để vậy đi"
- Em không đồng tình với ý kiến trên. Anh nói vậy là anh quá bảo thủ, structure anh đưa ra anh phải bảo vệ được trước ae dev, lí do nguyên nhân cái gì cũng phải logic. Ae học hỏi, người ta có quyền đặt câu hỏi. Nếu anh là 1 lead giỏi, anh sẽ giải thích thích đáng... Em lấy ví dụ với em: "structure này mặc dù không phải best practice nhưng nó đảm bảo được tiến độ nhanh, đúng tiến độ dự án. Mặc dù a biết còn các structure khác hay hơn nhưng a nghĩ thời điểm khác thích hợp hơn chúng ta nên họp team và cùng nhau nghiên cứu, lựa chọn một structure tốt nhất cho các dự án tiếp theo..bla bla"
2. "Thằng dev thì cứ làm theo những gì thằng lead bảo, hết giờ thì về."
- Đây là thằng culi chứ không phải thằng dev. Mấy ae dev như tụi em thường rất thông minh và chịu khó học hỏi.
3. " Bao giờ mày lên lead thì mày sẽ hiểu cảm giác mấy nói mà mấy thằng dev đéo nghe nó cay thế nào."
- Đấy là anh phải xem lại cách quản lí, dẫn dắt team của anh. Người leader yếu kém mới cay cú với ae. Anh phải hỏi tại sao ae không nghe lời mình mà nghe lời leader khác.
4. Code thế nào cũng được, miễn là nó chạy đúng. Refactor lại là 1 câu chuyện khác.
- Vấn đề em đưa ra không phải là code đã chạy rồi và refactor lại. Anh có thể đọc lại.
5. Mã nguồn chỉ là phù du, chạy đúng mới là vĩnh cửu.
- Bản vẽ, kĩ thuật là phù du. nhà ở được, chui ra chui vào được là được.

Thay mặt một số ae dev cảm ơn anh

N.V.T said:

Rách việc, dự án nó code thế nào thì cứ để vậy đi. Thằng dev thì cứ làm theo những gì thằng lead bảo, hết giờ thì về. Bao giờ mày lên lead thì mày sẽ hiểu cảm giác mấy nói mà mấy thằng dev đéo nghe nó cay thế nào.

Code thế nào cũng được, miễn là nó chạy đúng. Refactor lại là 1 câu chuyện khác.

Mã nguồn chỉ là phù du, chạy đúng mới là vĩnh cửu.

khunglongtim3 said:

Thằng repo chả để làm gì chỉ rối thêm. Tôi gọi thẳng model luôn.

_Worker_of_MUFC_ said:

Hic, bạn thực sự có vấn đề trong việc tư duy logic.

Ngay từ đầu bạn chủ thớt đã cố gắng đưa vấn đề về việc đơn giản hoá, tránh việc 1 Service sẽ sinh ra nhiều repo. Giờ mới chỉ có 1 câu query join mà bạn sinh ra tới 3 repo class để handle. Thử tưởng tượng với business logic phức tạp thì vục mặt vào đống repo kia có mà chết à?

Thích Màu Hường said:

Lót dép hóng các bạn trẻ cãi nhau... mô hình 3 lớp từ old school với chuyện quản lý source version mà cũng chém tới page thứ 6 à.

lam vung lau lam said:

^
Đây là vấn đề quản lý độ phức tạp của phần mềm. Không phải tự nhiên người ta nghĩ ra bao nhiêu kiến trúc, paradigms, design pattern, ddd... Nhiều kiến trúc đã lạc hậu, như mô hình ba lớp mà anh nói, nhiều design pattern đã bị coi là anti pattern. Nên ở đây cãi nhau cũng chả có gì lạ.

Tôi đọc source code cũng nhiều. Nhiều người đi code 20 năm mà code một dự án kiến trúc còn thay lên thay xuống. Thế mà có một cậu ở trên tự hào chỉ cần thay 1 config là đã có thể xyz...

amoniac06 said:

ko hẳn là rối việc, với việc migrate từ DB này qua DB khác (Mysql, mongo, MSSQL,... ) thì chia repository xử lý rất nhanh

khunglongtim3 said:

Thằng repo chả để làm gì chỉ rối thêm. Tôi gọi thẳng model luôn.

gaveezy said:

anh làm rối rắm thế, tôi expose DB ra ngoài cho app kết nối thẳng tới luôn, đỡ phải làm backend luôn, có bug thì cứ đẩy qua app

phongkyanh said:

Cái mà anh bảo không được là cái mà SOLID nó hướng đến đấy anh. Và tôi thấy cái đấy hoàn toàn khả thi nhé. Cái mindset của cậu kia quá là ổn luôn.
//Với cả tôi thấy anh không nên lôi năm kinh nghiệm code ra để khẳng định một điều gì đấy. Vì thế giới nó luôn vận động và phát triển. Nhất là trong môi trường IT nữa, lý thuyết ngày hôm nay đúng mai có thể đã sai rồi. Với cả chắc gì mấy ông nhiều kinh nghiệm hơn đã ngon hơn mấy ông ít kinh nghiệm hơn. "Trường giang sóng sau xô sóng trước" anh ơi

4nh7i3m said:

Tối ưu là khi Business Logic nó thay đổi, mở rộng thì developer nó chỉ phải sửa một chỗ chứ ko phải sửa cả trăm chỗ bằng search và replace.

Tối ưu là khi anh thay cả hệ thống database từ local lên cloud hay thậm chí đổi qua thằng database khác thì anh chỉ việc thay cái config hay đổi cái library implementation của repo là xong chứ không phải là ngưng cả hệ thống lại chờ Team Dev.

lam vung lau lam said:

Nếu có 1 module mà anh chỉ cần thay đổi config là có thể thay đổi được cách hoạt động của nó, thì module đó là blackbox và anh là end user. Anh không thể extend được cái module đó. Như vậy mà gọi là SOLID?
https://www.brandonsmith.ninja/blog/libraries-not-frameworks

phongkyanh said:

Mindset của người ta như này mà anh. Sao anh lại chỉ focus vào mỗi cái thay config thế kia. Tôi thấy cái mindset đấy nó giống kiểu abstract thinking và nếu áp dụng được cái đấy vào code thì quá là flexible và extendable còn gì nữa anh. Người ta nói thế tôi chả thấy chỗ nào không ổn cả?

lam vung lau lam said:

^
đúng như anh nói. dự án crud thì 90% logic là data access.
vậy tại sao không dùng begin .. commit mà lại cần Unit Of Work? tại sao không dùng sql mà lại dùng linq?
ORM bắt anh phải map 1-1 giữa c# object và table, hay người ta gọi là database driven design.

Thích Màu Hường said:

Vì cái nào tiện hơn thì mình dùng thôi. Những cái a nói là các implementation của thằng Data Access Service. Còn thằng Business Service nhìn xuống nó có quan tâm là bên dưới xài cái gì đâu.

via theNEXTvoz for iPhone

lam vung lau lam said:

ừ nhưng anh không viết sql thì anh ko được sử dụng features của DBMS cung cấp, và anh phải học api của EntityFramework, NHibernate

Thích Màu Hường said:

Về vấn đề của chủ thớt: chủ thớt đề xuất setup project theo mô hình 3 lớp như vậy xét về mặt kỹ thuật là hợp lý. Team leader và những người trong team chủ thớt phản đối mà ko nêu được lý do chính đáng (ví dụ scope project nhỏ, ko cần mở rộng và reuse, deadline hạn hẹp, team members thiếu kinh nghiệm..v..v..) thì rất đáng trách và làm nhiều người ko phục. Cái này có thể ko phải những người đó dốt (mặc dù có thể dốt thật) mà do cố chấp, ko muốn bị 1 thằng nhóc 9x dạy đời.

Lời khuyên cho chủ thớt: mình chỉ gợi ý, quyền quyết định là của thằng tech lead. Nó ko nghe thì thôi, vì chung quy người chịu trách nhiệm là nó, là PM, Team Leader. Nếu cái đề xuất của mình nó ko nghe theo mà ko ảnh hưởng gì lớn tới công việc của mình, như trường hợp này design dở nhưng lại code khoẻ hơn, kiểu mì ăn liền thì thôi chấp nhận làm theo. Lâu dài ko học hỏi đc gì hay thì kiếm cty khác.

Về vụ kiến trúc dự án nên là 3 lớp hay 2 lớp:
Một dự án bất kỳ Web, Windows, Mobile thường sẽ như vầy:
UI (Web, Win, Mobile) hoặc REST API -> Business Service -> Data Access Service (persistence layer).

Business Service là phần core nên 90% các dự án là sẽ có. Còn Data Access Service là để CRUD vào database, XML file, cloud storage... hay cái quái gì khác ko cần biết. Mục đích của nó là tách phần logic đọc ghi data với phần business service để có thể Unit Test business service bằng cách mock thằng Data Access Service, hoặc thay đổi database (ví dụ thay thế implementation của layer này từ MySQL sang cloud storage, hoặc XML...). Data Access Service có thể có hoặc không thì tuỳ vào scope dự án.

Dự án nhỏ, chỉ đơn thuần CRUD, ko có nhu cầu đổi database (thực tế khá hiếm) như dự án của chủ thớt thì nên đi theo cái này: UI -> Business Service. Lý do: các dự án CRUD thì phần core business logic rất ít, nếu đẻ ra Data Access Service thì đa số phần logic thật sự nằm ở tầng này vì làm CRUD và phải đảm bảo tính Unit of Work của nó (update 2 tables cùng 1 transaction) như vậy business service chỉ có nhiệm vụ pass qua lại DAS và UI thì chi bằng implement thẳng nó vào business service luôn, chấp nhận fix thằng database vì nó hiếm thay đổi mà. Tất nhiên làm vậy thì chỉ có thể Unit Test thằng UI (controller), còn business service thì integration test nhưng cũng nên như vậy vì CRUD nên làm integration test.

Về Repository và ORM:
Tôi ko gọi thằng này là Repository mà gọi là Data Access Service như bên trên. Hiện tại có ORM nên tôi sẽ ko tạo ra Repository tương ứng cho từng table mà sử dụng trực tiếp hibernate session, dbContext, dapper... trong phần implementation của Data Access Service luôn. Làm như vậy tận dụng được hết khả năng của ORM framework vì nó support tận răng rồi (CRUD, mapping, transaction) . Trường hợp duy nhất cần Repository là khi có ý định thay đổi luôn cả ORM framework như vậy phải abstract luôn cả thằng này (cực hiếm) trong khi hiện tại các ORM framework đã support thay đổi nhiều database luôn rồi.

Về vụ conflict source:
Nguyên tắc rất đơn giản: 1 người chỉ được code trên 1 file, phân chia làm sao để tránh xài chung thì thì ko có conflict: Ví dụ phân front end/back end thì từ controller, html, css, js là anh front end làm, code business service, data access service, SQL script là anh backend làm. Còn ko thì phân theo Use Case, module.

@phongkyanh: được chưa thím

Nếu cái đề xuất của mình nó ko nghe theo mà ko ảnh hưởng gì lớn tới công việc của mình, như trường hợp này design dở nhưng lại code khoẻ hơn, kiểu mì ăn liền thì thôi chấp nhận làm theo. Lâu dài ko học hỏi đc gì hay thì kiếm cty khác.

Thích Màu Hường said:

Khi nào gặp dự án mà gần trăm tables. Mổi tables chừng 50, 100 columns a ngồi làm CURD bằng cách viết SQL đi rồi thấy tại sao người ta đẻ ra ORM. Tất nhiên ORM cũng có hạn chế khi update batch data nhiều dòng, join nhiều tables. Bởi vậy mới đẻ ra thằng Dapper là để dung hoà cả 2 đó.

via theNEXTvoz for iPhone

lam vung lau lam said:

đừng nói với tôi gần trăm tables, mỗi table 50, 100 columns mà anh viết bằng linq dễ hơn sql nhé. dùng dapper là a đang viết sql nhé. tôi đang nói orm thay sql bằng linq kìa

Thích Màu Hường said:

Thật ra ORM để làm CRUD, đỡ tốn công sức vụ mapping thôi. Những câu query phức tạp, join nhiều table, ví dụ hàm Search, reports thì tôi viết stored procedure, views ở database. Nói chung cũng rất it khi viết linq trên code. A xài ORM nhưng đâu ai cấm anh viết stored procedure đâu.

lam vung lau lam said:

Thế thì tôi đề xuất anh bỏ hẳn EntityFramework hay NHibernate, để dev của anh không dùng table để thiết kế domain model nữa - giống "best practices" của contoso university. Và, project của anh không có 2 cách làm cho cùng 1 việc. Nó chỉ có nhược điểm là hơi mất công khi insert, update thôi.

lam vung lau lam said:

Vì cái abstract thinking của anh mà rất nhiều thư viện vô dụng (nhưng rất nhiều người dùng) được viết như AutoMapper, FluentValidation.

lam vung lau lam said:

ừ nhưng anh không viết sql thì anh ko được sử dụng features của DBMS cung cấp, và anh phải học api của EntityFramework, NHibernate

Thích Màu Hường said:

Cái này thi tuỳ dự án mà chọn cách implementation của Data Access Service dùng cái nào. Dự án a thấy ko dùng ORM ok thì ok thôi. Nó đâu liên quan domain driven hay database driven đâu.

Phần domain ở Business Service nó chỉ quan tâm các interface là IDataAccessService thôi. Nó ko cần biết anh dùng SQL, EntityFramework hay NHibernate bên dưới.

Nói luôn vụ switch database bằng config là được nhé:
Ví dụ interface IDataAccessService có các implementation là EFDataAccessService, NhDataAccessService, AdoDataAccessService, CloudDataAccessService, XmlDataAccessService. Anh switch qua lại các module này bằng config là được nhé.

4nh7i3m said:

1.
Giờ ai nói và về select field nhanh hơn với select star thì thôi mấy anh tự làm cái test đi. Mấy anh lựa cái bảng nào nhiều dòng nhất mà mấy anh có làm cái SQL "Select * from table where id =" với cái "Select id from table where id=" xem coi nó lệch bao nhiêu ms. Đấy là phần SQL.

Rồi về phần mapping giờ mấy anh tự code một cái function map giữa 2 object A và B (copy giá trị 1-1). Một cái map full 20 properties một cái map 1 property. Rồi mấy anh đo xem coi nó lệch bao nhiêu ms.

Sau khi làm xong mấy anh báo lại xem mấy anh tối ưu được bao nhiêu ms.

Tôi báo kết quả luôn là 0ms. Tức là về performance các anh lợi được là 0ms.
Nhưng cũng phải nói các anh tiết kiệm được vài kb bộ nhớ trong quá trình map đấy.

Rồi giờ các anh đứng trước quyết định là mấy anh làm spaghetti code để tiết kiệm vài kb bộ nhớ trong vài giây thì có đáng không?

Tối về tôi viết cái test: SELECT * và SELECT 1 field cần thiết cho anh xem lệch 0ms cái đầu anh.

4nh7i3m said:

Cám ơn anh đã cho tôi ánh sáng. Sẵn anh cho tôi biết cái table của anh như thế nào, số dòng và số cột trong đó để chúng ta rõ ràng hơn là tôi "ngu" hay thằng thiết kế SQL mà anh có "ngu" nhé.

Anh hãy đập vào mặt tôi một cái trường hợp mà tôi chỉ câm nín nghe tiếng anh chửi thôi.

Bét rì ga.

4nh7i3m said:

Anh chỉ cần làm đúng cái câu query tôi ghi ở bài trên. Hãy đập vào mặt tôi rằng câu
"select * from table where id=" với "select id table where id=" nó lệch nhau vài ms đi. Còn tất cả những cái khác với tôi đều chỉ là "ngụy biện".

quandaso said:

Sao lại chuyển đề tài sang sql rồi =]]
Nói vụ này nói chung select * ko phải lúc nào cũng tệ.
Nhưng ông nào bảo chỉ tốn có tí memory là sai rồi nhé, ví dụ tôi có db images chứa raw image bên trong, mỗi image cỡ 1->5 MB. Tôi cần map 10k record để export excel chẳng hạn. Lúc đấy SELECT* chả vỡ mồm à

katoshi said:

Thì ông kia chém quá mà. ko cần raw images ( vì ai mà làm thế) , chỉ cần field đó là image_urls thôi cũng thấy đc

quandaso said:

Ai bảo ko ai làm thế, ảnh bên y tế vẫn lưu raw image bình thường nhé. Nó hơi ngu si nhưng đc cái quản lí nó dễ, phân quyền các kiểu nữa

4nh7i3m said:

Anh chỉ cần làm đúng cái câu query tôi ghi ở bài trên. Hãy đập vào mặt tôi rằng câu
"select * from table where id=" với "select id table where id=" nó lệch nhau vài ms đi. Còn tất cả những cái khác với tôi đều chỉ là "ngụy biện".

gaveezy said:

lệch kha khá đấy (bảng tầm 15 columns)
View attachment 309409

4nh7i3m said:

Cám ơn bạn. Bạn cho cái definition của table là đẹp. Nếu được cho kiểu Server nữa để mọi người dễ tham khảo.

Rồi giờ các anh đứng trước quyết định là mấy anh làm spaghetti code để tiết kiệm vài kb bộ nhớ trong vài giây thì có đáng không?

4nh7i3m said:

@gaveezy: Rồi cám ơn bạn rất nhiều luôn. Như vậy tôi đã bị đập vào mặt là execution lệch 5ms và fetch time là 20ms. Như tôi chém gió là 0ms thì là "xạo lìn" (không phải tôi cố tình "xạo lìn" mà tôi test trên database tôi có đếch hiểu sao nó có 0ms (execution time) thôi. Tôi đã lựa cái bảng to nhất tôi có rồi).
Giờ tôi đợi tiếp anh @katoshi với anh @quandaso chứng minh tiếp là lệch khoảng bao nhiêu ms nũa.

Vậy đúng như ý tôi muốn hỏi và chứng minh giữa select * với select fied

Vài giây là sao, đối với tôi vài giây lệch là hệ thống treo cmnr, thậm chí response trả về > 100ms thôi đã là không được rồi

4nh7i3m said:

Anh @lam vung lau lam đã out topic rồi làm tôi không được học thêm cái gì mới.

Bàn về con người.
Ở trên các bạn nói abstract thinking hay abstraction thì đúng chuyên môn và hàn lâm quá rồi. Tôi thì chỉ có một cái giải thích thôi đó là vì tôi lười. Tôi lười phải chạy theo các thay đổi của tụi bên Business và cả theo chef tổng nên tôi phải làm sao mà khi có những thay đổi diễn ra, tôi phải không bị stress khi sửa các thay đổi đó vào.

Sẽ có những thời khắc mà các quyết định nó hoàn toàn mang tính "chính trị" chứ chẳng phải gì về công nghệ cái con mịa gì cả. Ví dụ đang local chạy tốt việc gì phải lên cloud, đang SQL tốt việc gì phải qua NoSQL. Đó là vì nỗi sợ của những người không hiểu. Họ sợ bị tụt hậu, họ sợ bị bỏ lỡ. Mà những người đó toàn là CEO, Chủ tịch quản trị, CIO thôi, toàn dân Politics cả chứ nền tảng technical được bao nhiêu so với dân chuyên môn. Nhưng đó là cách thế giới vận hành và phát triển.

Bàn về tech.

1.
Giờ ai nói và về select field nhanh hơn với select star thì thôi mấy anh tự làm cái test đi. Mấy anh lựa cái bảng nào nhiều dòng nhất mà mấy anh có làm cái SQL "Select * from table where id =" với cái "Select id from table where id=" xem coi nó lệch bao nhiêu ms. Đấy là phần SQL.

Rồi về phần mapping giờ mấy anh tự code một cái function map giữa 2 object A và B (copy giá trị 1-1). Một cái map full 20 properties một cái map 1 property. Rồi mấy anh đo xem coi nó lệch bao nhiêu ms.

Sau khi làm xong mấy anh báo lại xem mấy anh tối ưu được bao nhiêu ms.

Tôi báo kết quả luôn là 0ms. Tức là về performance các anh lợi được là 0ms.
Nhưng cũng phải nói các anh tiết kiệm được vài kb bộ nhớ trong quá trình map đấy.

Rồi giờ các anh đứng trước quyết định là mấy anh làm spaghetti code để tiết kiệm vài kb bộ nhớ trong vài giây thì có đáng không?

2. Rồi thứ 2 là về Raw SQL.
- Các anh nói các anh thích viết raw sql. It's ok. Đó là sở thích của các anh. Nhưng đứng ở vị trí của tôi trước dự án 20-30 dev. Các anh kêu tôi dùng raw sql á? Một là các anh bị điên. Hai là các anh bị khùng. Ai sẽ quản lý nổi cái đống raw sql đó? Convention, SQL Function, SQL Injection... ai sẽ validate? Rồi khi thay đổi Business Logic dùng cột A thay cột B thì ai sẽ ngồi search và replace rồi test lại là mọi thứ đều đúng?

- Rồi các anh gào lên là cần Raw SQL để tạo report cho nó performance. Tôi đồng ý với các anh luôn. Nhưng quan trọng là các anh đặt cái Raw SQL đó ở đâu? Các anh sẽ tự hào quăng luôn câu SQL đó vào trong code của các anh. Và tôi chúc các anh maintain nó vui vẻ cả phần đời còn lại của các anh.
Với tôi, quy tắc quan trọng nhất khi dùng ORM đó là khi anh không thể dùng ORM để viết một câu SQL anh muốn thì câu SQL đó phải nằm ở Database Server chứ không phải ở code của anh. Bởi vì, rõ ràng câu SQL đó nó gắn với một loại Database nhất định chứ không còn abstract đủ để dùng ORM nữa. Khi để câu SQL đó trong code tức là anh đã tự bắn vào "chim" mình, sau này khi có thay đổi thì anh ăn đạn đừng kêu trách ai.

Thế thôi. Đó là ý của tôi. Tầm nhìn nó phụ thuộc vào vị trí các anh đứng. Luôn nhớ là như vậy.

nosql

Giờ ai nói và về select field nhanh hơn với select star

mapping 20 properties vs 1 properties

4nh7i3m said:

@Nipin: Anh gì ơi, tôi cũng chả biết anh đang chửi hay khen tôi nữa. Anh viết rõ dài nhưng tôi đọc không hiểu anh muốn nói gì. Chắc là chửi tôi ngu viết code không tối ưu (chắc vậy) hay là sao? Vì anh nêu các trường hợp server cũ, máy cũ, mạng yếu, đi làm bị sếp chửi về nhà bị vợ la...

Anh thì kêu tôi không có kinh nghiệm làm với hệ thống 20 triệu request mỗi ngày. Trên 100ms là time out luôn. Cứ đừng nói chờ vài giây.
Anh thì nói không phù hợp với các hệ thống cũ. Có thể chạy lâu hơn vài giây.

Trong khi tôi hỏi các anh siêu nhơn chỉ cho tôi làm sao tối ưu cái hàm GetUserById với N trường hợp cần các fields khác nhau thì các anh như là không thấy ấy?

Thôi tôi xin phép chào các anh. Tôi đi đây.

Tôi chửi việc anh đưa luận điểm không đủ chặt chẽ.

À chửi thêm cái nosql nữa.

4nh7i3m said:

Anh @lam vung lau lam đã out topic rồi làm tôi không được học thêm cái gì mới.

Bàn về con người.
Ở trên các bạn nói abstract thinking hay abstraction thì đúng chuyên môn và hàn lâm quá rồi. Tôi thì chỉ có một cái giải thích thôi đó là vì tôi lười. Tôi lười phải chạy theo các thay đổi của tụi bên Business và cả theo chef tổng nên tôi phải làm sao mà khi có những thay đổi diễn ra, tôi phải không bị stress khi sửa các thay đổi đó vào.

Sẽ có những thời khắc mà các quyết định nó hoàn toàn mang tính "chính trị" chứ chẳng phải gì về công nghệ cái con mịa gì cả. Ví dụ đang local chạy tốt việc gì phải lên cloud, đang SQL tốt việc gì phải qua NoSQL. Đó là vì nỗi sợ của những người không hiểu. Họ sợ bị tụt hậu, họ sợ bị bỏ lỡ. Mà những người đó toàn là CEO, Chủ tịch quản trị, CIO thôi, toàn dân Politics cả chứ nền tảng technical được bao nhiêu so với dân chuyên môn. Nhưng đó là cách thế giới vận hành và phát triển.

Bàn về tech.

1.
Giờ ai nói và về select field nhanh hơn với select star thì thôi mấy anh tự làm cái test đi. Mấy anh lựa cái bảng nào nhiều dòng nhất mà mấy anh có làm cái SQL "Select * from table where id =" với cái "Select id from table where id=" xem coi nó lệch bao nhiêu ms. Đấy là phần SQL.

Rồi về phần mapping giờ mấy anh tự code một cái function map giữa 2 object A và B (copy giá trị 1-1). Một cái map full 20 properties một cái map 1 property. Rồi mấy anh đo xem coi nó lệch bao nhiêu ms.

Sau khi làm xong mấy anh báo lại xem mấy anh tối ưu được bao nhiêu ms.

Tôi báo kết quả luôn là 0ms. Tức là về performance các anh lợi được là 0ms.
Nhưng cũng phải nói các anh tiết kiệm được vài kb bộ nhớ trong quá trình map đấy.

Rồi giờ các anh đứng trước quyết định là mấy anh làm spaghetti code để tiết kiệm vài kb bộ nhớ trong vài giây thì có đáng không?

2. Rồi thứ 2 là về Raw SQL.
- Các anh nói các anh thích viết raw sql. It's ok. Đó là sở thích của các anh. Nhưng đứng ở vị trí của tôi trước dự án 20-30 dev. Các anh kêu tôi dùng raw sql á? Một là các anh bị điên. Hai là các anh bị khùng. Ai sẽ quản lý nổi cái đống raw sql đó? Convention, SQL Function, SQL Injection... ai sẽ validate? Rồi khi thay đổi Business Logic dùng cột A thay cột B thì ai sẽ ngồi search và replace rồi test lại là mọi thứ đều đúng?

- Rồi các anh gào lên là cần Raw SQL để tạo report cho nó performance. Tôi đồng ý với các anh luôn. Nhưng quan trọng là các anh đặt cái Raw SQL đó ở đâu? Các anh sẽ tự hào quăng luôn câu SQL đó vào trong code của các anh. Và tôi chúc các anh maintain nó vui vẻ cả phần đời còn lại của các anh.
Với tôi, quy tắc quan trọng nhất khi dùng ORM đó là khi anh không thể dùng ORM để viết một câu SQL anh muốn thì câu SQL đó phải nằm ở Database Server chứ không phải ở code của anh. Bởi vì, rõ ràng câu SQL đó nó gắn với một loại Database nhất định chứ không còn abstract đủ để dùng ORM nữa. Khi để câu SQL đó trong code tức là anh đã tự bắn vào "chim" mình, sau này khi có thay đổi thì anh ăn đạn đừng kêu trách ai.

Thế thôi. Đó là ý của tôi. Tầm nhìn nó phụ thuộc vào vị trí các anh đứng. Luôn nhớ là như vậy.

4nh7i3m said:

Tôi chém gió chứ có phải bảo vệ luận văn đâu mà anh kêu tôi đưa luận điểm với bench test. Mấy anh làm quá.


Tôi có nói gì về nosql đâu nhỉ? Tôi chỉ nói nhiều khi do politics trong công ty chef mới lên muốn có nguồn gió mới đổi sql thành nosql mặc dù sql nó chả có vấn đề gì thì sao lại chửi tôi nhỉ? Hay anh chửi lộn tôi với ai thế.

phần 3: GetUserByID, không thể select theo từng field vì khi đó rất khó maintain, nhưng cũng ko thể select * nếu table quá lớn. Giải pháp tôi từng làm cho team đơn giản là tách theo từng cụm. Ví dụ GetAll -> UserEntity, GetCredential -> UserCredentialEntity, GetContact -> UserContactEntity, GetProfile -> UserProfileEntity. Nếu cần 2 loại entity sẽ GetAll. Tất nhiên nó ko tối ưu, nhưng nó sẽ cân bằng cho cả performance và maintainance.

phần 2: ORM nó có nhiều tác dụng hơn vậy nhiều. Tất nhiên nó cũng có trade off, đó là performance. Cái anh đang nói thì chỉ cần query builder là đủ, tôi là dev trong 1 repo có 500 dev, vẫn đang dùng query builder thay vì ORM vì vấn đề performance.

4nh7i3m said:

@gaveezy: Rồi cám ơn bạn rất nhiều luôn. Như vậy tôi đã bị đập vào mặt là execution lệch 5ms và fetch time là 20ms. Như tôi chém gió là 0ms thì là "xạo lìn" (không phải tôi cố tình "xạo lìn" mà tôi test trên database tôi có đếch hiểu sao nó có 0ms (execution time) thôi. Tôi đã lựa cái bảng to nhất tôi có rồi).
Giờ tôi đợi tiếp anh @katoshi với anh @quandaso chứng minh tiếp là lệch khoảng bao nhiêu ms nũa.

Vậy đúng như ý tôi muốn hỏi và chứng minh giữa select * với select fied




@Edit: Tôi tìm ra lỗi của tôi rồi. Trên tool nó hiện 00:00:00 mà tôi đọc thành 00:00:00.0000. Xin lỗi anh em tức là có lệch vài ms. Nhưng tôi vẫn để bài viết như cũ không sửa nhé.

quandaso said:

Vài giây là sao, đối với tôi vài giây lệch là hệ thống treo cmnr, thậm chí response trả về > 100ms thôi đã là không được rồi. Khi hệ thống nó scale lên 15M/20M request trên ngày ông sẽ hiểu dù 20ms nó đã đáng giá như nào.
Tôi ko biết ông đã vận hành hệ thống bao giờ chưa, nếu chưa tôi quay lại cái video cho ông mở rộng tầm mắt, khi select * 1 triệu bản ghi và select id nó khác nhau nhiều như thế nào

Kết quả select * mất 48s, select id mất 1.6 giây tức là nhanh gấp 30 lần. Tận 30 lần đấy

Sniper_V2 said:

Test như này k ổn đâu thím, Query lần 2 trên cùng 1 bảng thì đã có caching rồi. Thím test lại thử xem . Ngày xưa em nhớ xài oracle thì select * và select field hầu như không chênh lệch quá nhiều
@còn về ORM hay Raw SQL thì rõ ràng là ORM rồi, SQL chỉ viết khi thực sự cần tối ưu, dễ bảo trì bảo dưỡng, đỡ hỏng vặt, tưởng tượng 1 ngày công ty thím tuyển vài ba đứa newbie/junior, mà task yêu cầu viết 1 câu SQL hơi complex 1 tí thì tụi nó có mà ngồi đến năm sau cũng chưa viết ra đâu nhé

4nh7i3m said:

Đấy là ý tôi muốn trình bày. Cái chính là như anh trình bày, 1 cái GetUserById nó phân nhánh thành 4, 5 hàm như thế. Rồi mỗi khi có cái củ cải gì mới, thằng Dev nó lại định nghĩa một cái hàm mới . Đến cuối cùng nó là một đám hổ lốn chỉ để đưa về thông tin của một User. Mà đấy chỉ là cho 1 User thôi í, giờ chúng ta scale lên 10 Entities hay 100 Entities (như Order, Product, Role...) thì code nó phình ra tới mức nào nên tôi chỉ nói là tôi chọn hướng tối ưu theo cách nhìn của tôi chứ tôi không chọn theo hướng lợi thêm được vài giây (tôi không dám nói milli giây luôn vì sẽ có thằng nhảy vào chửi tiếp). Và bằng chứng là các hệ thống tôi chịu trách nhiệm vẫn vận hành tốt.

Tôi ví dụ một thằng tôi đã làm là ADAC ở Đức nhé. Đây là một dịch vụ khởi nguồn là dịch vụ kéo xe bị hư giữa đường và giờ nó thành một hệ thống khổng lồ bán đủ thứ trên đời trừ phim xxx. Tôi cũng chả bao giờ hỏi tới là có bao nhiêu request một ngày nên tôi không chắc về lượng request đâu nhưng tôi chỉ biết ở Đức thằng này là dịch vụ lớn duy nhất về mảng này.

90tr dân Đức hàng ngày lên đây mua sắm bảo hiểm, dịch vụ, gọi báo lỗi xe,... thì tôi nghĩ chắc cũng đông đông và nó chả có vấn đề mịa gì về performance cả.

Cả hệ thống đếch có tối ưu mịa gì với raw sql cả. Select fields thì có trong các trường hợp đặc biệt vì yêu cầu thôi (mà rất ít vì toàn đọc chủ yếu từ cache ra). Còn report thì những gì cần nhiều thời gian thì như tôi đã nói ở trên.

Các hệ thống nó tách biệt nhau ra, chạy trên các server khác nhau, thêm vào load balancer, cache system, replication tôi thật sự không hiểu mấy anh cứ khè mấy chục ms với tôi làm gì. Tôi đếch hiểu mấy hệ thống của các anh sao nó phải phụ thuộc quá nhiều vào Database server như thế.

Tôi thấy vấn đề nó chỉ nằm ở 20-30 dev tụi nó trình độ khác nhau. Quản mới là mệt, sẽ có 2,3 thằng nerd như các anh suốt ngày hò hét với tui về performance cũng có 2,3 thằng nó kệ mẹ cuộc đời check in vô phát sập mẹ luôn cái dev. Thế thôi.


Tôi đồng ý khi cần nhanh, rất nhanh thì tối ưu hết tất cả và dùng raw sql là cần thiết như tôi đã ghi ở trên. Và thật sự tôi cũng không may mắn dẫn được đội 500 dev nên cũng không biết nó khủng cỡ nào. Bạn thật quá hạnh phúc.

• 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?

tomoco said:

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?

Gâu Gâu Gâu Gâu said:

phần 1: có người test rồi.

phần 2: ORM nó có nhiều tác dụng hơn vậy nhiều. Tất nhiên nó cũng có trade off, đó là performance. Cái anh đang nói thì chỉ cần query builder là đủ, tôi là dev trong 1 repo có 500 dev, vẫn đang dùng query builder thay vì ORM vì vấn đề performance.

phần 3: GetUserByID, không thể select theo từng field vì khi đó rất khó maintain, nhưng cũng ko thể select * nếu table quá lớn. Giải pháp tôi từng làm cho team đơn giản là tách theo từng cụm. Ví dụ GetAll -> UserEntity, GetCredential -> UserCredentialEntity, GetContact -> UserContactEntity, GetProfile -> UserProfileEntity. Nếu cần 2 loại entity sẽ GetAll. Tất nhiên nó ko tối ưu, nhưng nó sẽ cân bằng cho cả performance và maintainance.

snowboy273 said:

GetUserById select theo từng field cho từng trường hợp nếu dùng EF Core + Automapper Projection vẫn làm dc nhé, lúc đó chỉ cần đưa vào từng IMapper instance có profile khác nhau là select field khác nhau liền. Tất nhiên output của hàm GetUserById phải định nghĩa đủ props cho tất cả các trường hợp, nhưng câu query mà EF Core generate ra thì tuỳ vô IMapper instance

tomoco said:

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?

Reishou said:

Cái điều này mình cũng khúc mắc bao lâu nay, mong các bác chỉ dạy

using (MyDbContext ctx = new MyDbContext())
{
  var studentRep = new Repository<Student>(ctx);
  var standardRep = new Repository<Standard>(ctx);
  var studentToStandard = studentRep.GetAll().Join(standardRep.GetAll(),
                        student => student.StandardRefId,
                        standard => standard.StandardId,
                        (stud, stand) => new { Student=stud, Standard=stand }).ToList();
}

// ...
unitOfWork.CourseRepository.Insert(course);
unitOfWork.Save();
//...
unitOfWork.CourseRepository.Delete(id);
unitOfWork.Save();
// ...
unitOfWork.Dispose();

// ...
courseDAS.Insert(course);
//...
courseDAS.Delete(id);

tomoco said:

xin link tham khảo được ko ạ

snowboy273 said:

GetUserById select theo từng field cho từng trường hợp nếu dùng EF Core + Automapper Projection vẫn làm dc nhé, lúc đó chỉ cần đưa vào từng IMapper instance có profile khác nhau là select field khác nhau liền. Tất nhiên output của hàm GetUserById phải định nghĩa đủ props cho tất cả các trường hợp, nhưng câu query mà EF Core generate ra thì tuỳ vô IMapper instance

Gâu Gâu Gâu Gâu said:

ko dùng EF nhưng đoán là object user chứa nhiều properties, thím chỉ fetch những cái nào cần, số còn lại null hết?
làm như vậy thì khó maintain, vì khi sử dụng object user đó phải biết những field nào đc fetch những field nào không.

gaveezy said:

lệch kha khá đấy (bảng tầm 15 columns)
View attachment 309409

thiensau ver1 said:

Bên mình cũng y vậy, có điều chỗ service code nhiều quá, nên mình đẻ ra thêm 2 layer nữa, là validator để validate và business để handle các logic, mà thấy trong service vẫn còn xử lý nhiều, chắc do chia ngu quá

_Worker_of_MUFC_ said:

Hic, bạn thực sự có vấn đề trong việc tư duy logic.

Ngay từ đầu bạn chủ thớt đã cố gắng đưa vấn đề về việc đơn giản hoá, tránh việc 1 Service sẽ sinh ra nhiều repo. Giờ mới chỉ có 1 câu query join mà bạn sinh ra tới 3 repo class để handle. Thử tưởng tượng với business logic phức tạp thì vục mặt vào đống repo kia có mà chết à?

tomoco said:

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?

tomoco said:

Nhân tiện hỏi thêm vì trên này return ra full model nhưng khi trả về cho client thì chỉ trả về những field cần thiết, vậy bên client nên làm ntn cũng với bài toán trên? xây dựng thật nhiều model hay ntn?

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?

RPG29 said:

Bạn nên dùng DTO - Data Transfer Object thay vì trả full model/entity.
Model/Entity chứa cả state và behavior, còn thông tin trả cho client chủ yếu là state nên trả thông qua DTO riêng cho dễ handle.

tomoco said:

vâng chắc em nói hơi khó hiểu, thì đúng là phía server chỉ trả về những thông tin cần thiết thôi, nhưng như vậy thì client lại phải xây dựng từng model cho từng màn hình phải ko?

RPG29 said:

Bạn nên dùng DTO - Data Transfer Object thay vì trả full model/entity.
Model/Entity chứa cả state và behavior, còn thông tin trả cho client chủ yếu là state nên trả thông qua DTO riêng cho dễ handle.

Khang.Hy.Gia.222 said:

DTO với entity như nhau thôi. bác cứ tập trung tiểu tiết mà k trả lời vào trọng tâm

RPG29 said:

Mình không cho rằng DTO và Entity như nhau trừ khi CRUD 100%

tomoco said:

các bác lạc đề quá, câu hỏi của em đơn giản thôi 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.

tomoco said:

các bác lạc đề quá, câu hỏi của em đơn giản thôi 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.

soledad86 said:

Đúng. Giống view-model trong M-V-VM. Vm đó chưa có mà cần dùng thì tạo thêm. Tôi thấy ko vấn đề gì cả đâu.

khunglongden said:

K cần thừa k sao cả. Bạn có chắc là màn list k thay đổi và sau này nó cần 9/10 field thì sao?

khunglongden said:

K cần thừa k sao cả. Bạn có chắc là màn list k thay đổi và sau này nó cần 9/10 field thì sao?

tomoco said:

các bác lạc đề quá, câu hỏi của em đơn giản thôi 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.

tomoco said:

các bác lạc đề quá, câu hỏi của em đơn giản thôi 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.

tomoco said:

các bác cho hỏi e là việc call đến các hệ thống khác: Ví dụ: AWS S3, MS PowerBI hoặc đơn giản là 1 cái API thời tiết chẳng hạn thì các bác thường để ở đâu nhỉ? Để ở service thì cũng ko đúng lắm vì nó là business logic?

RPG29 said:

Cái này thì nên tách làm interface và implementation riêng.

Interface: Storage, BI, Weather -> Cái này là core của mình
Implementation: S3 implement Storage, PowerBI implement BI, AccuWeather implement Weather -> Cái này là infrastructure.

Tách làm 2 để có thể đổi implementation mà không thay đổi nghiệp vụ của core. Còn nếu mà thấy đơn giản quá, không có nhu cầu đổi impl thì thôi khỏi tách.

tomoco said:

em hiểu cái Bác nói nhưng là để ở đâu nhỉ? service, repository hay ở đâu dc?

tomoco said:

em hiểu cái Bác nói nhưng là để ở đâu nhỉ? service, repository hay ở đâu dc?

tomoco said:

em hiểu cái Bác nói nhưng là để ở đâu nhỉ? service, repository hay ở đâu dc?

• Tôi chưa thấy chỗ họ implement caching, nhưng nếu làm tôi cho là nên làm ở các Repo.
• Đối với các phức tạp và chạy nặng tôi chủ trương dùng RawSql ở các repo (hi sinh tính linh hoạt switch qua lại giữa các loại db)

/src/Modules/SimplCommerce.Module.Orders/Areas/Orders/Controllers/OrderController.cs said:

using System.Linq;
using System.Threading.Tasks;
using Microsoft.AspNetCore.Authorization;
using Microsoft.AspNetCore.Mvc;
using Microsoft.EntityFrameworkCore;
using SimplCommerce.Infrastructure.Data;
using SimplCommerce.Module.Core.Extensions;
using SimplCommerce.Module.Core.Services;
using SimplCommerce.Module.Orders.Areas.Orders.ViewModels;
using SimplCommerce.Module.Orders.Models;

namespace SimplCommerce.Module.Orders.Areas.Orders.Controllers
{
[Area("Orders")]
[Authorize]
public class OrderController : Controller
{
private readonly IMediaService _mediaService;
private readonly IRepository<Order> _orderRepository;
private readonly IWorkContext _workContext;
private readonly ICurrencyService _currencyService;

public OrderController(IRepository<Order> orderRepository, IWorkContext workContext, IMediaService mediaService, ICurrencyService currencyService)
{
_orderRepository = orderRepository;
_workContext = workContext;
_mediaService = mediaService;
_currencyService = currencyService;
}

[HttpGet("user/orders")]
public async Task<IActionResult> OrderHistoryList()
{
var user = await _workContext.GetCurrentUser();
var model = await _orderRepository
.Query()
.Where(x => x.CustomerId == user.Id && x.ParentId == null)
.Include(x => x.OrderItems).ThenInclude(x => x.Product).ThenInclude(x => x.ThumbnailImage)
.Include(x => x.OrderItems).ThenInclude(x => x.Product).ThenInclude(x => x.OptionCombinations).ThenInclude(x => x.Option)
.OrderByDescending(x => x.CreatedOn).ToListAsync();

var model2 = model.Select(x => new OrderHistoryListItem(_currencyService)
{
Id = x.Id,
CreatedOn = x.CreatedOn,
SubTotal = x.SubTotal,
OrderStatus = x.OrderStatus,
OrderItems = x.OrderItems.Select(i => new OrderHistoryProductVm
{
ProductId = i.ProductId,
ProductName = i.Product.Name,
Quantity = i.Quantity,
ThumbnailImage = i.Product.ThumbnailImage.FileName,
ProductOptions = i.Product.OptionCombinations.Select(o => o.Value)
}).ToList()
}).ToList();

foreach (var item in model2)
{
foreach (var product in item.OrderItems)
{
product.ThumbnailImage = _mediaService.GetMediaUrl(product.ThumbnailImage);
}
}

return View(model2);
}

[HttpGet("user/orders/{orderId}")]
public async Task<IActionResult> OrderDetails(long orderId)
{
var user = await _workContext.GetCurrentUser();

var order = _orderRepository
.Query()
.Include(x => x.ShippingAddress).ThenInclude(x => x.District)
.Include(x => x.ShippingAddress).ThenInclude(x => x.StateOrProvince)
.Include(x => x.ShippingAddress).ThenInclude(x => x.Country)
.Include(x => x.OrderItems).ThenInclude(x => x.Product).ThenInclude(x => x.ThumbnailImage)
.Include(x => x.OrderItems).ThenInclude(x => x.Product).ThenInclude(x => x.OptionCombinations).ThenInclude(x => x.Option)
.Include(x => x.Customer)
.FirstOrDefault(x => x.Id == orderId);

if (order == null)
{
return NotFound();
}

if (order.CustomerId != user.Id)
{
return BadRequest(new { error = "You don't have permission to view this order" });
}

var model = new OrderDetailVm(_currencyService)
{
Id = order.Id,
IsMasterOrder = order.IsMasterOrder,
CreatedOn = order.CreatedOn,
OrderStatus = (int)order.OrderStatus,
OrderStatusString = order.OrderStatus.ToString(),
CustomerId = order.CustomerId,
CustomerName = order.Customer.FullName,
CustomerEmail = order.Customer.Email,
ShippingMethod = order.ShippingMethod,
PaymentMethod = order.PaymentMethod,
PaymentFeeAmount = order.PaymentFeeAmount,
Subtotal = order.SubTotal,
DiscountAmount = order.DiscountAmount,
SubTotalWithDiscount = order.SubTotalWithDiscount,
TaxAmount = order.TaxAmount,
ShippingAmount = order.ShippingFeeAmount,
OrderTotal = order.OrderTotal,
OrderNote = order.OrderNote,
ShippingAddress = new ShippingAddressVm
{
AddressLine1 = order.ShippingAddress.AddressLine1,
CityName = order.ShippingAddress.City,
ZipCode = order.ShippingAddress.ZipCode,
ContactName = order.ShippingAddress.ContactName,
DistrictName = order.ShippingAddress.District?.Name,
StateOrProvinceName = order.ShippingAddress.StateOrProvince.Name,
Phone = order.ShippingAddress.Phone
},
OrderItems = order.OrderItems.Select(x => new OrderItemVm(_currencyService)
{
Id = x.Id,
ProductId = x.Product.Id,
ProductName = x.Product.Name,
ProductPrice = x.ProductPrice,
Quantity = x.Quantity,
DiscountAmount = x.DiscountAmount,
ProductImage = x.Product.ThumbnailImage.FileName,
TaxAmount = x.TaxAmount,
TaxPercent = x.TaxPercent,
VariationOptions = OrderItemVm.GetVariationOption(x.Product)
}).ToList()
};

foreach (var item in model.OrderItems)
{
item.ProductImage = _mediaService.GetMediaUrl(item.ProductImage);
}

return View(model);
}
}
}