The repository abstract persistence access, whatever storage it is. That is its purpose. The fact that you're using a db or xml files or an ORM doesn't matter. The Repository allows the rest of the application to ignore persistence details. This way, you can easily test the app via mocking or stubbing and you can change storages if it's needed. Today you might use MySql, tomorrow you'll want to use NoSql or Cloud Storage. Do that with an ORM!

Vozer cấp tiến said:

Thế repository nó là lớp nào trong 3 lớp trên hả thím?

Pepe.The.Frog said:

Khai sáng cho tôi đi anh. Nếu anh đưa ra ví dụ cụ thể (có code) nào phải cần repo pattern mà ko dùng ORM hay design pattern dc ngoài mấy cái tôi đã nêu ở trên thì tôi tụt quần xin lỗi...

• Đơ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ề

lazloq said:

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.

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.

servuskevin said:

@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é.

Pepe.The.Frog said:

1. Domain model và object mapping model (trong EF nó gọi là Entity) không phải là một -> Đúng vì Entity thật sự là thuộc tầng Data Access Layer. Về mặt tổ chức code có thể phân tụi nó ra 2 module và dùng AutoMapper/DTO để map 2 thằng này khi lấy data lên.

2. Trường hợp ko sử dụng EF nữa thì tất nhiên anh phải đập đi xây lại tầng Data Access layer và effort bỏ ra là như nhau giữa việc có xài Repository hay ko vì:

1. Nếu xài Repository: -> Re-implement lại Repository bỏ đi cái EF, xài cái mới
2. Nếu ko xài Repository -> Re-implement lại Service bỏ đi cái EF, xài cái mới

Vấn đề là logic nặng là ở tầng Data Access layer chứ Business Service khá ít nên việc tôi gọi trực tiếp EF bên trong business service cũng chẳng có gì sai và vẫn support Unit Test/Mock bình thường vì bản thân EF nó support chuyện đó rồi.

Hơn hết, việc đổi ORM là việc rất hiếm và đa số là ko đáng như tôi đã nói ở #12:
https://voz.vn/t/thao-luan-reposito...khi-da-co-orm-framework.490455/#post-15758632

Tôi cố tình khích các anh vào để kéo page đấy. Ai khó chịu thì lượn thôi.

servuskevin said:

@Pepe.The.Frog tui già quá rồi nên ko hiểu nổi suy nghĩ của mấy anh trẻ bây giờ.

Tui và bạn bè già của tui thì ráng sống vui vẻ, hoà đồng, tạo không khí vui vẻ để mọi người chia sẻ trao đổi, làm việc.

Còn giờ thì câu view, click bait, khích bác lẫn nhau.

Tôi không hiểu cái kiểu quái thai gì đang diễn ra bây giờ nữa.

Thời tui là sống sao để mọi người yêu thương. Còn giờ càng bị chửi càng dzui hay sao vậy?

Therefore, use a Repository, the purpose of which is to encapsulate all the logic needed to obtain object references. The domain objects won’t have to deal with the infrastructure to get the needed references to other objects of the domain. They will just get them from the Repository and the model is regaining its clarity and focus. The Repository may store references to some of the objects. When an object is created, it may be saved in the Repository, and retrieved from there to be used later. If the client requested an object from the Repository, and the Repository does not have it, it may get it from the storage. Either way, the Repository acts as a storage place for globally accessible objects.