thảo luận [.NET] Topic thảo luận các vấn đề xoay quanh .Net

tại sao lại chuyển vậy bác. thấy ngta đánh giá tốc độ Dapper cao hơn EF Core.
Ưu điểm lớn nhất của EF là strong type, lỡ thằng dev nào sửa code mà bị sai thì khi compile code nó báo lỗi ngay.

Chứ lỡ sửa câu raw sql mà sai tên 1 column thì ối giời ơi :sexy_girl:

Mà giờ cần tốc độ thì hầu hết sẽ tạo thêm 1 cái Redis để cache kết quả, chứ không query nhiều vào DB nữa, vậy nên Dapper có nhanh hơn EF mấy cũng không ý nghĩa nhiều.
 
Dapper for reads thì nên viết raw sql hay là sp vậy bác. Nếu viết raw sql thì viết thẳng vào code ạ bác ?
Nên viết raw sql, viết query ra file riêng rồi read từ file và execute. Đừng dùng sp, performance chả hơn raw sql được bao nhiêu (không đáng kể) mà quản lý code, logic khổ lắm.

P/s: nếu được thì nghĩ giải pháp khác chứ raw sql cũng khổ.
 
Ưu điểm lớn nhất của EF là strong type, lỡ thằng dev nào sửa code mà bị sai thì khi compile code nó báo lỗi ngay.

Chứ lỡ sửa câu raw sql mà sai tên 1 column thì ối giời ơi :sexy_girl:

Mà giờ cần tốc độ thì hầu hết sẽ tạo thêm 1 cái Redis để cache kết quả, chứ không query nhiều vào DB nữa, vậy nên Dapper có nhanh hơn EF mấy cũng không ý nghĩa nhiều.
Thím cho mình hỏi với những câu query mà điều kiện where không cố định (điển hình như form search, điều kiện lọc theo từ khóa, theo khoảng thời gian bất kỳ) thì cache thế nào cho hiệu quả nhỉ?
 
Thím cho mình hỏi với những câu query mà điều kiện where không cố định (điển hình như form search, điều kiện lọc theo từ khóa, theo khoảng thời gian bất kỳ) thì cache thế nào cho hiệu quả nhỉ?

Vẫn tạo câu query nhiều điều kiện bình thường thím. Sau đó lấy 100-200 row đầu tiên lưu vào Redis để cache (vì thường user tìm kiếm cũng chỉ quan tâm mấy kết quả đầu tiên)
 
Lướt 1 vòng Linkedin, Vietnamwork thì thấy số lượng job .NET chỉ bằng 1/5 so với Java mà toàn yêu cầu 3y+ :sweat:
Ủa e nghe nói jav toàn fresher với senn, không có junior-middle nên dân ngoại đạo nhảy sang khó hơn mà?
Còn .Net vẫn tuyển rank junior?
ghXpJrI.png
 
Nên viết raw sql, viết query ra file riêng rồi read từ file và execute. Đừng dùng sp, performance chả hơn raw sql được bao nhiêu (không đáng kể) mà quản lý code, logic khổ lắm.

P/s: nếu được thì nghĩ giải pháp khác chứ raw sql cũng khổ.
Tôi thấy việc viết raw sql ra file riêng về mặt quản lý logic khác gì việc viết store nhỉ ??

Lại còn tốn performance cho việc đọc file nữa.

Thay vì thế anh có thể tạo 1 folder chứa code store procedure, mỗi khi có chỉnh sửa gì đẩy lên git cả team đều nhìn được mà ?
 
Tôi thấy việc viết raw sql ra file riêng về mặt quản lý logic khác gì việc viết store nhỉ ??

Lại còn tốn performance cho việc đọc file nữa.

Thay vì thế anh có thể tạo 1 folder chứa code store procedure, mỗi khi có chỉnh sửa gì đẩy lên git cả team đều nhìn được mà ?
Trước kia dùng stored procedure thì team mình vẫn lưu lại script, có git đầy đủ, nói chung là quản lý source y hệt như dùng file raw sql. Nhưng dùng stored procedure thì risk liên quan đến con người lớn hơn, tạo ra backdoor để thay đổi code/logic mà không cần thông qua các pipeline.
Ví dụ điển hình là hotfix bằng update stored procedure mà quên không lưu lại script mới.
Việc đọc raw script từ file thì cũng không ảnh hưởng gì lớn tới performance, nhưng hạn chế được lỗi liên quan đến con người.
 
Trước kia dùng stored procedure thì team mình vẫn lưu lại script, có git đầy đủ, nói chung là quản lý source y hệt như dùng file raw sql. Nhưng dùng stored procedure thì risk liên quan đến con người lớn hơn, tạo ra backdoor để thay đổi code/logic mà không cần thông qua các pipeline.
Ví dụ điển hình là hotfix bằng update stored procedure mà quên không lưu lại script mới.
Việc đọc raw script từ file thì cũng không ảnh hưởng gì lớn tới performance, nhưng hạn chế được lỗi liên quan đến con người.
Mình đồng ý với thím vụ dùng store có những lúc dev members fix bằng cách run script mà không update trong file, nhưng mình nghĩ chủ yếu do con người và cái này ae trong team có thể sửa đc

P/s: nghe như mình bênh store nhưng thực sự ghét viết store (và cả query thuần vc), trước có lần vào dự án mới đọc store toàn 5-10k dòng ám ảnh từ đó tới giờ
 
Trước kia dùng stored procedure thì team mình vẫn lưu lại script, có git đầy đủ, nói chung là quản lý source y hệt như dùng file raw sql. Nhưng dùng stored procedure thì risk liên quan đến con người lớn hơn, tạo ra backdoor để thay đổi code/logic mà không cần thông qua các pipeline.
Ví dụ điển hình là hotfix bằng update stored procedure mà quên không lưu lại script mới.
Việc đọc raw script từ file thì cũng không ảnh hưởng gì lớn tới performance, nhưng hạn chế được lỗi liên quan đến con người.

Mình đồng ý với thím vụ dùng store có những lúc dev members fix bằng cách run script mà không update trong file, nhưng mình nghĩ chủ yếu do con người và cái này ae trong team có thể sửa đc

P/s: nghe như mình bênh store nhưng thực sự ghét viết store (và cả query thuần vc), trước có lần vào dự án mới đọc store toàn 5-10k dòng ám ảnh từ đó tới giờ
2 thím tham khảo liquibase rồi phân quyền thôi run alter stored ấy.
 
Anh chị xem giúp em CV này của em còn thiếu gì không ạ. Em apply fresher mãi mà không thấy bên nào gọi ạ. Hic. Em cảm ơn anh chị ạ :>>
 

Attachments

  • CV_DeveloperC#_.NET_BuiDucHuy.pdf
    288.4 KB · Views: 18
Back
Top