thảo luận [Thảo Luận] Sử dụng Entity Framework thế nào cho sang

  • Người tạo chủ đề Người tạo chủ đề Pepe.The.Frog
  • Ngày bắt đầu Ngày bắt đầu

Pepe.The.Frog

Senior Member
Sau bao nhiêu dự án xài thằng này thì tôi thấy có những thứ cần tránh khi xài thằng này để 1 team dev đủ thể loại trình độ từ gà con lon ton tới đại bàng, senior, expert có thể làm việc hiệu quả:

1. Disable lazy load. Xài lazy load hại nhiều hơn lợi thế đíu nào Microsoft lại để default là enable lazy load.
2. Không map one-to-many. Dẹp, dẹp hết các thể loại này.
3. Data types, constraints, null, not null… phải match 100% từ Entity tới database. Mấy a dev gà con lon ton hay senior trình gà đều ko để ý cái này. Lỗi xảy ra debug mệt vl, vì data issue.

Còn gì nữa để từ từ nghĩ ra rồi chửi. :shame:

via theNEXTvoz for iPhone
 
không map one to many nghĩa là sao thím? bỏ hết fk reference giữa các bảng á
vrESGSY.png
 
ví dụ có 2 class là Department vs Employee quan hệ 1-n
thay vì Include thì có phải thì có phải chia làm 2 query
Query đầu thì select Department
Query sau thì select Employee vs điều kiện Id ràng buộc rồi map vô property ICollection<Employee>Employees của class Department đúng k ạ
:too_sad:mong các cao nhân chỉ giáo đứa gà mờ như em 1 cách nhẹ nhàng ạ
 
Thím có thể giải thích lý do tại sao làm như vậy lại hay hơn là map table?

Làm như vậy ko hay hơn nhưng đảm bảo những anh dev "gà con lon ton" không mắc phải những lỗi n + 1 queries nếu lazyload enable và cũng chỉ load data cần thiết chứ ko load hết tất cả.

ví dụ có 2 class là Department vs Employee quan hệ 1-n
thay vì Include thì có phải thì có phải chia làm 2 query
Query đầu thì select Department
Query sau thì select Employee vs điều kiện Id ràng buộc rồi map vô property ICollection<Employee>Employees của class Department đúng k ạ
:too_sad:mong các cao nhân chỉ giáo đứa gà mờ như em 1 cách nhẹ nhàng ạ

Đúng rồi tách ra làm 2. Còn lên trên domain thì tại sao phải biểu diễn cái relationship one-to-many trên domain?

Ví dụ màn hình xem nhân viên của phòng ban thì bao giờ cũng load 2 thông tin phòng ban rồi load cái list nhân viên theo DepartmentId có paging chứ ai lại load 1 department chứa 1 list ICollection<Employee> 10.000 employee trong đó :ah:

Bỏ luôn cái property list employee ra khỏi deparment giùm đê
 
Làm như vậy ko hay hơn nhưng đảm bảo những anh dev "gà con lon ton" không mắc phải những lỗi n + 1 queries nếu lazyload enable và cũng chỉ load data cần thiết chứ ko load hết tất cả.



Đúng rồi tách ra làm 2. Còn lên trên domain thì tại sao phải biểu diễn cái relationship one-to-many trên domain?

Ví dụ màn hình xem nhân viên của phòng ban thì bao giờ cũng load 2 thông tin phòng ban rồi load cái list nhân viên theo DepartmentId có paging chứ ai lại load 1 department chứa 1 list ICollection<Employee> 10.000 employee trong đó :ah:

Bỏ luôn cái property list employee ra khỏi deparment giùm đê
load tt phòng ban với nhân viên của pb đấy thì context.Set<PhongBan>.Where(x=>x.id==id).Include(x=>x.Nhanvien) là có tt của phòng ban + nhân viên của phòng ban đấy còn gì.
.AsSplitQuery() vào là nó gen ra 2 query . Này là eager loading chứ có phải lazy loading đâu
 
Sửa lần cuối:
load tt phòng ban với nhân viên của pb đấy thì context.Set<PhongBan>.Where(x=>x.id==id).Include(x=>x.Nhanvien) là có tt của phòng ban + nhân viên của phòng ban đấy còn gì.
Thích thành 2 query thì .AsSplitQuery() vào là xong. Này là eager loading chứ có phải lazy loading đâu

Rồi một a gà con lon ton sẽ ko gọi include vào mà đẩy cái object PhongBan ra ngoài. Rồi for loop cái cái list nhân viên ấy….

Code a ấy vẫn chạy, rồi thậm chí a ta quăng nó lên UI đẩy cả entity ra service, controller rồi nó seriealize ra json… Cho dù cái service chỉ cần mổi phòng ban thôi…

Ai kiểm soát dc chuyện đó

via theNEXTvoz for iPhone
 
Rồi một a gà con lon ton sẽ ko gọi include vào mà đẩy cái object PhongBan ra ngoài. Rồi for loop cái cái list nhân viên ấy….

Code a ấy vẫn chạy, rồi thậm chí a ta quăng nó lên UI đẩy cả entity ra service, controller rồi nó seriealize ra json… Cho dù cái service chỉ cần mổi phòng ban thôi…

Ai kiểm soát dc chuyện đó

via theNEXTvoz for iPhone
ơ thì thím wrap nó vào 1 cái method GetListNhanVienByPhongBanId(int id) ở trong cái Phongban repo
à mà thím này anti repository pattern
k1Ewd2r.png

ps: chưa thấy ai làm như kiểu thím nói ở trên luôn ấy
 
ơ thì thím wrap nó vào 1 cái method GetListNhanVienByPhongBanId(int id) ở trong cái Phongban repo
à mà thím này anti repository pattern
k1Ewd2r.png

ps: chưa thấy ai làm như kiểu thím nói ở trên luôn ấy

Cái này ko liên quan repo. Thím chưa hiểu vấn đề, thôi tôi ko muốn cãi. :doubt:
 
Thím có thể giải thích lý do tại sao làm như vậy lại hay hơn là map table?
đỡ đc issue về n + 1 ( thật ra entity framework cũng có cách giải quyết vấn đề này rồi vd như Graph Entity, nhưng mấy bạn thiếu kinh nghiệm/ chưa đào sâu thì khả năng là chưa đc tiếp xúc ) :)
 
đỡ đc issue về n + 1 ( thật ra entity framework cũng có cách giải quyết vấn đề này rồi vd như Graph Entity, nhưng mấy bạn thiếu kinh nghiệm/ chưa đào sâu thì khả năng là chưa đc tiếp xúc ) :)

Ờ, người có kinh nghiệm thì code kiểu nào cũng được, ng ta hiểu rõ từng query trên linq nó translate ra sql thế nào. Ng ta biết cả enity graph, lúc nào track change, changes cái gì. Lúc nào nó sẽ lazyload để hit db...

Nhưng 1 dự án mấy anh được như vậy? Còn các a "gà con lon ton" thì code chạy được thôi. Ngay cả mấy a pro cũng có lúc mistake vì đâu ai nhớ là có include. Tốt nhất tắt cho xong.
 
Giả sử category với product quan hệ là 1-n (1 category có nhiều product)

Vậy khi tôi muốn lấy toàn bộ product của 1 category, thì đầu tiên theo anh thì:
1. Lấy category ra trước
2. Từ category lấy ra ở trên -> Dùng id của category đó để query thêm 1 lần nữa lấy toàn bộ Product?

Mình hiểu đúng ý thím không @Pepe.The.Frog
 
Sửa lần cuối:

Thống kê chủ đề

Ngày tạo
Pepe.The.Frog,
Người trả lời cuối
slowly_but_steadily,
Trả lời
81
Lượt xem
10.218
Quay lại
Lên đầu trang