Trong lớp truy cập dữ liệu và logic nghiệp vụ riêng biệt, tôi có thể sử dụng các lớp khung thực thể trong lớp nghiệp vụ không?

Question

Trong truy cập dữ liệu riêng biệt & lớp logic nghiệp vụ, tôi có thể sử dụng các lớp khung thực thể trong lớp nghiệp vụ không?

EDIT: Tôi không nghĩ rằng tôi sẽ cần phải trao đổi lớp truy cập dữ liệu từ logic nghiệp vụ của tôi trong tương lai (nghĩa là SQL Server), tuy nhiên tôi sẽ cho lớp giao diện người dùng. Do đó, câu hỏi đặt ra là có vấn đề gì lớn hơn khi sử dụng các lớp học EF cho tôi trong lớp kinh doanh? Có vẻ như sẽ có ít hệ thống ống nước hơn.

Answer 1

Thông thường, "thực hành tốt nhất" cách tiếp cận sẽ là một cái gì đó như thế này:

• trong lớp dữ liệu của bạn, bạn có thực thể EF mà có được nạp từ và lưu trữ lại các cơ sở dữ liệu

• trong lớp Doanh nghiệp của bạn, bạn có các đối tượng miền của riêng mình (chỉ các lớp C# đơn giản) đại diện cho dữ liệu mà ứng dụng của bạn cần làm việc. Những thứ đó có thể ít nhiều giống hệt với thực thể lớp dữ liệu, hoặc chúng có thể chứa một số thực thể "nguyên tử" để tạo nên một đối tượng nghiệp vụ hoặc chúng có thể rất khác nhau. Để giảm bớt sự cần thiết cho nhiều câu lệnh gán tay trái (để di chuyển các giá trị thuộc tính qua lại giữa các thực thể lớp dữ liệu và các đối tượng lớp nghiệp vụ), bạn nên kiểm tra các công cụ như AutoMapper. lên "ánh xạ" giữa các loại đối tượng tương tự và cho phép bạn dễ dàng gán những loại lui

• lớp UI của bạn (s) sau đó sẽ hình dung và đại diện cho đối tượng lớp kinh doanh cho người sử dụng cung cấp thông tin và/hoặc thao tác

Lợi ích là mô hình miền cấp doanh nghiệp của bạn đại diện cho các đối tượng kinh doanh thực tế mà bạn đang làm việc và trở nên độc lập hơn hoặc ít hơn thực sự được lưu trữ trong lớp dữ liệu. Ngoài ra, điều này tránh "dán" lớp giao diện người dùng của bạn vào một công nghệ truy cập dữ liệu cụ thể.

Tất nhiên - đó là phương pháp hay nhất được đề xuất cho ứng dụng quy mô doanh nghiệp, nơi bạn có thể cần trao đổi lớp truy cập dữ liệu, v.v. đang làm, và rằng bạn đang "khóa" chính bạn vào EF nếu bạn sử dụng các thực thể EF tất cả các cách thức thông qua các lớp kinh doanh vào giao diện người dùng. Nếu đó là ok với bạn và kịch bản ứng dụng của bạn - không có lý do cụ thể để không làm điều đó. Các thực thể EF là các lớp đối tượng .NET hoàn toàn hợp lệ - chúng đơn giản xuất phát từ một lớp cơ sở chung (EntityObject thay vì object) và chúng có một số lượng "hành lý" nhất định xuất hiện. Nhưng không có gì ngăn cản bạn sử dụng những thực thể EF đó trong suốt ứng dụng của bạn.

Answer 2

Như với tất cả các câu hỏi về bản chất này, câu trả lời là tùy thuộc. Nếu bạn muốn có một sự tách biệt rõ ràng về logic truy cập dữ liệu của bạn và lớp nghiệp vụ, tôi sẽ nói không. Nếu đó là những gì bạn đang nhắm đến, tôi sẽ sử dụng một mẫu kho lưu trữ và IoC để xây dựng lớp truy cập dữ liệu, sau đó bạn có thể hoán đổi trong một DAL sơ khai cho các mục đích thử nghiệm đơn vị và sau đó mang lại truy cập cơ sở dữ liệu khi bạn đến thử nghiệm chức năng.

Answer 3

Nếu bạn cần để có thể thay đổi cách bạn truy cập cơ sở dữ liệu mà không cần phải viết lại nhiều mã, bạn nên giữ EF ra khỏi lớp kinh doanh. Bạn có thể sử dụng đơn vị công việc và các mẫu kho lưu trữ để đạt được điều này; truy cập tất cả các chức năng của tầng dữ liệu thông qua giao diện. Nếu bạn bỏ EF, các giao diện vẫn giữ nguyên, bạn chỉ cần thay đổi các lớp thực hiện.

Tuy nhiên, có các đối số không sử dụng UoW và kho lưu trữ, chính là DbContext đã cung cấp cho bạn nhiều tính năng đó.

Tôi đã bắt đầu một dự án có UoI và kho lưu trữ ở lớp dữ liệu và không có tham chiếu EF nào ở lớp doanh nghiệp. Khi tôi tiến bộ, tôi cảm thấy rằng tôi chỉ đang làm việc cho bản thân mình và bỏ chúng. Thay vào đó, tôi sử dụng truy cập ngữ cảnh từ tầng nghiệp vụ, thực hiện bất kỳ chuyển đổi nào tôi cần từ DTO sang cấp độ kinh doanh POCO.

Trong trường hợp của tôi, tôi tự tin gắn bó với EF. Nếu bạn không, hãy xem xét cách tiếp cận nào phù hợp với bạn.