Drinkfood1905
Senior Member
Mình code ror thì kb pattern thớt ns là gì :v toàn dùng orm thôi
Share các thím 1 study case apply repository. Tôi có tình huống thế này:
Trong hệ thống e-commerce, model SalesOrder của tôi gồm những property sau:
SalesOrder
-> Customer information
-> Shipping/Billing address
-> Item list
Tôi có các lớp Services xử lý business logic, nhận input đầu vào là 1 object SalesOrder. (Gồm các nghiệp vụ trừ tồn, pick hàng, đóng gói, vận chuyển logistic v.v..)
Một ngày đẹp trời, công ty tôi ký hợp đồng với 1 đối tác bên ngoài, vận hành khâu xử lý đơn hàng. Trong hợp đồng ghi rõ là công ty tôi không được phép lưu dữ liệu khách hàng, thông tin khách hàng buộc phải gọi API về xử lý.
————————
Tôi xử dụng pattern repository từ đầu, trong repository, tôi viết các logic để build 1 model SalesOrder hoàn chỉnh (bao gồm collect thông tin các property customer, address, items) với SalesOrderRepository.get(order_code) trả về 1 model SalesOrder.
Với tình huống trên, tôi có 2 trường hợp:
- Đơn hàng thường, thông tin khách hàng tôi query trực tiếp trong DB của công ty
- Đơn hàng đối tác, thông tin khách hàng tôi gọi API để fetch về
Khi apply, tôi chỉ cần update ở phần repository, các lớp service business logic không update gì.
(*) Thông tin khách hàng là dữ liệu input để xử lý, không thay đổi trong suốt quá trình vận hành.
Share các thím 1 study case apply repository. Tôi có tình huống thế này:
Trong hệ thống e-commerce, model SalesOrder của tôi gồm những property sau:
SalesOrder
-> Customer information
-> Shipping/Billing address
-> Item list
Tôi có các lớp Services xử lý business logic, nhận input đầu vào là 1 object SalesOrder. (Gồm các nghiệp vụ trừ tồn, pick hàng, đóng gói, vận chuyển logistic v.v..)
Một ngày đẹp trời, công ty tôi ký hợp đồng với 1 đối tác bên ngoài, vận hành khâu xử lý đơn hàng. Trong hợp đồng ghi rõ là công ty tôi không được phép lưu dữ liệu khách hàng, thông tin khách hàng buộc phải gọi API về xử lý.
————————
Tôi xử dụng pattern repository từ đầu, trong repository, tôi viết các logic để build 1 model SalesOrder hoàn chỉnh (bao gồm collect thông tin các property customer, address, items) với SalesOrderRepository.get(order_code) trả về 1 model SalesOrder.
Với tình huống trên, tôi có 2 trường hợp:
- Đơn hàng thường, thông tin khách hàng tôi query trực tiếp trong DB của công ty
- Đơn hàng đối tác, thông tin khách hàng tôi gọi API để fetch về
Khi apply, tôi chỉ cần update ở phần repository, các lớp service business logic không update gì.
(*) Thông tin khách hàng là dữ liệu input để xử lý, không thay đổi trong suốt quá trình vận hành.
Case của thím tôi cũng từng làm rồi, nhưng dùng API của bên thứ 3 nó lại phát sinh nhiều vấn đề như bên đó đổi schema không giống db của mình, response time chậm hoặc timeout, khó làm transaction cho nhiều api create/update... Thế nên bên tôi chốt làm riêng cái service mới chứ không phải repository.
Tôi không chê repository pattern dở, chỉ là thấy giờ ít nơi xài thôi.
Sent from Samsung SM-G973F using vozFApp
Nếu xài dapper thì thằng dapper này coi như là extensioncủa Ado.net thôi, cái repository pattern chính là data access layer nên tôi ko tranh cãi, vẫn nên có 1 data access layer.
2 anh này... vấn đề tôi muốn nói là thậm chí cái thằng build repository nó "khôn" thì cũng là thừa vì ORM như Entity Framework/Hibernate nó làm hết rồi. Các anh build lại là phát minh lại cái banh xe nên tôi mới nói bullshit!
Giả sử ORM chỉ là miếng thịt bò, miếng cà chua trên 1 cái pizza thôi.
Còn Repo nó là cái bánh pizza. trong đó anh có thể có thêm hải sản ( ado) hoặc phô mai ( dapper) chạy trong đó cũng đc.
Anh ăn cái bánh có mỗi thịt bò + cà chua vẫn oke. Nhưng nếu tôi cần 1 service chạy pipeline qua nhiều cái services có cả ado, dapper thì dùng repo là right case rồi.
Cái tôi và anh kia nói là cái thằng build repo ngu có ý của nó đấy. Do anh dùng dao mổ bò đi thịt gà rồi thấy nó thừa thôi.
Case của tôi ban đầu cũng nghĩ là adapter thôi, nhưng tụi 3rd kia nó hầm bà lằng quá, thậm chí bên đó còn tắt luôn dev server vào cuối tuần nên tụi tôi muốn OT cũng không được. Thế là phải đẻ thêm 1 cái dummy mock server dể giả lập mớ API đó. Thấy vui hemVấn đề là cần thêm 1 cái services trong khi nó chỉ là adapter pattern thôi.
Cái hàm đó anh viết trực tiếp ở service. Lúc này sẽ inject dbContext vào service. dbContext sẽ THAY THẾ cho repository của anh.
Ví du: IProductManagementSerivce.Save(Product product);
Còn trường hợp muốn sử dụng hàm đó ở nhiều service thì anh viết extension methods cho dbContext, để gom cái logic đó vào 1 chổ.
....
Cũng như trên, anh tạo extension methods cho dbContext hoặc DbSet<Product>, hoặc helper class để gom cái logic đó lại thôi. Cái hàm này sẽ đứng ngang hàng với các hàm save, update của ORM. Nó ko phải là 1 layer cao hơn như Repository để wrap cái logic này lại.
if (today = saturay or sunday) return mock dataCase của tôi ban đầu cũng nghĩ là adapter thôi, nhưng tụi 3rd kia nó hầm bà lằng quá, thậm chí bên đó còn tắt luôn dev server vào cuối tuần nên tụi tôi muốn OT cũng không được. Thế là phải đẻ thêm 1 cái dummy mock server dể giả lập mớ API đó. Thấy vui hem
Ở đầu topic tui có nêu 2 ví dụ cần repository pattern mà anh em ko ai để ý. Chủ thớt thì trả lời như trên.
Tui có ý vầy thôi.
Ông thớt @Pepe.The.Frog ơi, cái cách giải quyết của ông chỉ là ông cố tình bỏ đi cái lớp Repository rồi đưa logic của nó lên lớp service hoặc static class hoặc extension methods. Rồi ông nhấn mạnh ko cần Repo Pattern. Ông bỏ Repository Pattern để đưa vào 1 đống anti pattern khác mà vẫn cho là đúng thì thôi.
Rồi DbContext rồi extension method nó là của Microsoft.net. thế giới lập trình nó ko chỉ có .net. Nó còn có Java,Python, Php,... nên cái Repository Pattern nó là cái abstract chung cho mọi ngôn ngữ. Nó giải quyết vấn đề chung.
Ông còn nói đũa với chén là một thì thôi tui đi. Nói gì nữa giờ.
Ở đầu topic tui có nêu 2 ví dụ cần repository pattern mà anh em ko ai để ý. Chủ thớt thì trả lời như trên.
Tui có ý vầy thôi.
Ông thớt @Pepe.The.Frog ơi, cái cách giải quyết của ông chỉ là ông cố tình bỏ đi cái lớp Repository rồi đưa logic của nó lên lớp service hoặc static class hoặc extension methods. Rồi ông nhấn mạnh ko cần Repo Pattern. Ông bỏ Repository Pattern để đưa vào 1 đống anti pattern khác mà vẫn cho là đúng thì thôi.
Rồi DbContext rồi extension method nó là của Microsoft.net. thế giới lập trình nó ko chỉ có .net. Nó còn có Java,Python, Php,... nên cái Repository Pattern nó là cái abstract chung cho mọi ngôn ngữ. Nó giải quyết vấn đề chung.
Ông còn nói đũa với chén là một thì thôi tui đi. Nói gì nữa giờ.
Ở đầu topic tui có nêu 2 ví dụ cần repository pattern mà anh em ko ai để ý. Chủ thớt thì trả lời như trên.
Tui có ý vầy thôi.
Ông thớt @Pepe.The.Frog ơi, cái cách giải quyết của ông chỉ là ông cố tình bỏ đi cái lớp Repository rồi đưa logic của nó lên lớp service hoặc static class hoặc extension methods. Rồi ông nhấn mạnh ko cần Repo Pattern. Ông bỏ Repository Pattern để đưa vào 1 đống anti pattern khác mà vẫn cho là đúng thì thôi.
Rồi DbContext rồi extension method nó là của Microsoft.net. thế giới lập trình nó ko chỉ có .net. Nó còn có Java,Python, Php,... nên cái Repository Pattern nó là cái abstract chung cho mọi ngôn ngữ. Nó giải quyết vấn đề chung.
Ông còn nói đũa với chén là một thì thôi tui đi. Nói gì nữa giờ.
if (today = saturay or sunday) return mock data
Ủa thế static method thì ông test kiểu gì? à à, quên mẹ mất, có cái thread ông ngồi chửi cái UN chết mẹ kìa nữa .=> Anh nói những cái tôi đưa vào là anti pattern?? WTF, mới anh chứng minh nó có bất cập gì đi
Đúng, nó ko chỉ có .Net nhưng tech stack khác đều có những cái tương đương mà. Và tôi tin mổi stack khác đều có 1 ORM tương ứng support đầy đủ rồi.
Ví dụ Java thì anh xài Hibernate thôi. Hay anh định build repository on top of hibernate?
Thôi bạn ah, chiều t6 rảnh rỗi vào đọc mấy cái thread trong này, tôi cay đến mức phải reg nick để phát biểu ý kiến, nhưng anh ếch kia vẫn ngồi trong cái giếng của ảnh, có nghe ai đâu@Pepe.The.Frog Tui xài NHibernate hơn 6 năm. Từ 2010 đến 2016. Và vâng, tui xài Repository Pattern. Tui cũng ko hiểu với mô hình session như NHibernate thì anh ko xài Repository Pattern anh xài kiểu gì chia sẻ tôi biết.
Còn Helper Class aka Static class , Extension method là anti-pattern. Anh wtf tôi làm gì khi ai cũng biết điều đó? Còn tui chán lên chém gió vậy thôi. Chứng minh với ảnh có mang tui đồng nào nuôi con đâu. Thôi nhé.
Các sếp họp với nhau, cam kết 2 tuần sau delivery, viết service mới sao thím! Người thì méo có, mà legacy logic thì đầy ai mà dám implement lại.Case của thím tôi cũng từng làm rồi, nhưng dùng API của bên thứ 3 nó lại phát sinh nhiều vấn đề như bên đó đổi schema không giống db của mình, response time chậm hoặc timeout, khó làm transaction cho nhiều api create/update... Thế nên bên tôi chốt làm riêng cái service mới chứ không phải repository.
Tôi không chê repository pattern dở, chỉ là thấy giờ ít nơi xài thôi.
Sent from Samsung SM-G973F using vozFApp
Nói là model SalesOrder vậy thôi, chứ các thông tin nó vẫn ở nằm các bảng con như (sales_orders, sales_order_customer, sales_order_address, sales_order_items)thím này trả lời 1 ý rồi đấy.
Còn cái nữa là trường hợp của thím có thể custom DbSet<SalesOrder>. Cái DbSet<SalesOrder> của Entity Framework chính là cái SalesOrderRepository đấy.
Thấy đang phát minh lại cái bánh xe chưa?
Đồng ý với câu nói này nè. Bản chất công việc là nên tách việc get/set data vào 1 layer khác với layer business, tên gọi của layer đó có thể là repository nếu nó đơn giản, hoặc nếu phức tạp thì gọi là service cũng được. Còn việc extend class có sẵn hay làm lại từ đầu bằng thủ công mỹ nghệ, mỗi cái có ưu nhược điểm khác nhau, tùy case mà dùng.
@Pepe.The.Frog Tui xài NHibernate hơn 6 năm. Từ 2010 đến 2016. Và vâng, tui xài Repository Pattern. Tui cũng ko hiểu với mô hình session như NHibernate thì anh ko xài Repository Pattern anh xài kiểu gì chia sẻ tôi biết.
Còn Helper Class aka Static class , Extension method là anti-pattern. Anh wtf tôi làm gì khi ai cũng biết điều đó? Còn tui chán lên chém gió vậy thôi. Chứng minh với anh có mang tui đồng nào nuôi con đâu. Thôi nhé.
Ủa thế static method thì ông test kiểu gì? à à, quên mẹ mất, có cái thread ông ngồi chửi cái UN chết mẹ kìa nữa .
Thôi zí zái vào pattern gì cho mệt, cứ tống mẹ vào vài cái static class. Đấy, thỏa lòng anh chưa
Thôi bạn ah, chiều t6 rảnh rỗi vào đọc mấy cái thread trong này, tôi cay đến mức phải reg nick để phát biểu ý kiến, nhưng anh ếch kia vẫn ngồi trong cái giếng của ảnh, có nghe ai đâu
Oh thì anh em share những vụ mình đã từng gặp để học hỏi lẫn nhau thôi, chứ có cách nào là phù hợp cho mọi hoàn cảnh đâu thím. Case của tôi chắc dính đến create/edit nên nó phưc tạp hơn.Các sếp họp với nhau, cam kết 2 tuần sau delivery, viết service mới sao thím! Người thì méo có, mà legacy logic thì đầy ai mà dám implement lại.
Với lại cái đoạn fetch thông tin khách hàng thì chỉ thuần read thôi chứ đâu có write gì đâu mà cần transaction. Logic repository đơn giản, fetch thông tin khách hàng không được thì quăng cái exception không query được đơn hàng, để retry lại thôi.