Tôi nghĩ rằng bạn đã bỏ lỡ một điểm là tại sao mọi người triển khai mẫu kho lưu trữ khi EF đã triển khai mẫu kho lưu trữ thông qua ObjectSet/DbSet?
Câu trả lời phổ biến là vì nhiều hướng dẫn khuyên bạn nên sử dụng nó mà không cần lý do chính đáng. Có các lý do hợp lệ không sử dụng Lớp lưu trữ trên ObjectSet/DbSet. Tuy nhiên tôi sẽ chỉ ra một số lý do là tại sao nó thích hợp hơn.
Bộ lọc mặc định Có nhiều trường hợp trong ứng dụng thực tế khi bạn cần bộ lọc mặc định. Ví dụ, các sản phẩm bị ngưng không được bán. Nếu bạn phơi bày các sản phẩm ObjectSet/DbSet trực tiếp sẽ có vấn đề nếu ai đó quên áp dụng bộ lọc mặc định. Nó cũng tránh được sự trùng lặp của logic. Bạn cũng có thể sửa đổi bộ lọc mặc định sau này mà không gặp phải sự cố nào.
public IQueriable<Product> GetAll()
{
return context.Products.Where(p => !p.IsDiscontinued);
}
mềm Xóa Nhiều ứng dụng sử dụng xóa mềm mại, nơi bạn giữ một cột như IsDeleted
mà không thực sự loại bỏ hàng.Bây giờ ObjectSet/DbSet có một phương thức Delete
nhưng một khi bạn gọi phương thức này, nó sẽ gán các giá trị null
cho các thuộc tính FK có thể vô hiệu hóa. Bạn có thể không muốn điều này.
public void Delete(Product product)
{
// can apply any other logic here
product.IsDeleted = true;
}
Chỉ đọc Entities Có rất nhiều tình huống mà một số ứng dụng khác có trách nhiệm tạo, xóa và cập nhật đối tượng và ứng dụng của bạn chỉ hiển thị các thực thể. Nhưng ObjectSet/DbSet cho thấy chức năng không được hỗ trợ trong trường hợp này. Một lợi ích khác trong trường hợp này là sử dụng tùy chọn NoTracking
để giảm thời gian hiện thực hóa thực thể.
Chuyển quyền truy cập dữ liệu mà không để lộ triển khai Có những trường hợp LINQ không đủ. Ở đây bạn có thể sử dụng SQL hoặc SP thô. Có một kho lưu trữ sẽ tránh để lộ các phương thức truy vấn/cập nhật khác nhau khi chức năng mà EF tiếp xúc không đủ.
Làm việc với cơ sở dữ liệu hiện tại Khi bạn không có sự sang trọng trong việc tạo cơ sở dữ liệu mà EF có khả năng xử lý. Bảng hiện tại có thể có các cột Sql Variant
, XML
. Sao chép các mục nhập vào một bảng khác và vô số các trường hợp khác mà bạn cần xử lý để giữ tính toàn vẹn của cơ sở dữ liệu.
Những kỹ thuật này có thể không có bằng chứng đạn nhưng sẽ có ích nếu tình huống yêu cầu. Những gì tôi sẽ đề nghị là không nhảy thẳng vào kho bạn nghĩ tốt hơn về việc thêm một lớp trừu tượng cần thiết để thực hiện các chức năng cần thiết.
EF không phải là một trừu tượng về dung lượng của bạn? Tại sao bạn cần bọc nó một lần nữa? Bạn kiểm tra đơn vị chính xác trong kho lưu trữ là gì? –
@EstebanAraya - bạn thường không kiểm tra đơn vị kho (bạn tích hợp kiểm tra chúng). Bằng cách tiêm một giao diện kho lưu trữ, bạn có thể giả lập rằng để kiểm tra đơn vị các lớp khác (logic nghiệp vụ) độc lập với một cơ sở dữ liệu. Mô hình có thể trả về bất kỳ bộ sưu tập nào của POCO mà các xét nghiệm của bạn cần. – TrueWill
EF là một trừu tượng cung cấp ánh xạ đối tượng, thực thể/theo dõi thay đổi. Kho lưu trữ kết thúc logic nghiệp vụ được sử dụng để truy cập dữ liệu. Logic giống như đã được mô tả trong câu trả lời của @ Eranga. nghĩa là truy vấn sản phẩm nhưng không bao gồm sản phẩm bị ngừng sản phẩm. Bằng cách sử dụng mẫu kho lưu trữ, bạn đảm bảo rằng các quy tắc nghiệp vụ của bạn luôn được theo dõi khi truy cập dữ liệu cơ bản. – BZink