Lời khuyên về việc thay thế Khối Truy cập Dữ liệu Thư viện Doanh nghiệp theo Entity Framework

Question

Một vài năm trước, chúng tôi đã phát triển một ứng dụng ASP.Net lớn (C#/.net 3.5). hoặc sử dụng SQL Server, Oracle, MySQL ... làm công cụ DB). Đối với điều đó, chúng tôi đã sử dụng Khối truy cập dữ liệu thư viện doanh nghiệp 4.1.

Nhưng bây giờ, khi chúng tôi đang trong giai đoạn "cải thiện hiệu suất/khả năng mở rộng", chúng tôi đang suy nghĩ về nâng cấp công nghệ hoặc thiết kế lại nền tảng ứng dụng của chúng tôi.

Vì vậy, câu hỏi đặt ra là: có lợi thế nào để chuyển sang Khung thực thể không? EF có giữ các tiêu chí "Cơ sở dữ liệu" không phụ thuộc của chúng tôi không? Hoặc chúng ta có nên tiếp tục thực hiện EntLib DAAB của chúng tôi nhưng nâng cấp lên phiên bản mới nhất (5.0)?

Cảm ơn

Answer 1

Có một số nhà cung cấp EF cho Oracle (Devart dotConnect for Oracle, DataDirect) và MySQL (Devart dotConnect for MySQL, MySQL Connector /NET), và Microsoft cung cấp một nhà cung cấp Entity Framework cho SQL Server, vì vậy không nên có bất kỳ vấn đề với độc lập cơ sở dữ liệu.

Answer 2

Vấn đề lớn nhất di chuyển giữa chúng không phải là về độc lập với cơ sở dữ liệu, đó là mẫu sử dụng về cơ bản là khác nhau. Khối truy cập dữ liệu (DAAB) chủ yếu là một trình bao bọc tiện lợi xung quanh ADO.NET. Nó làm cho nó dễ dàng hơn/ít gây phiền nhiễu để gọi thủ tục được lưu trữ, nhưng bạn vẫn còn đối phó với bộ dữ liệu hoặc độc giả dữ liệu. Nó không thực sự thay đổi cách bạn đang tương tác với cơ sở dữ liệu, nó chỉ làm cho nó ít gây phiền nhiễu.

Khuôn khổ thực thể, mặt khác, là về lập mô hình dữ liệu và ánh xạ đối tượng-quan hệ. Nó hoạt động ở mức cao hơn DAAB; bạn viết mã của bạn về các đối tượng của bạn, không phải về DataSets hoặc DataReaders. Nó tự động hóa các "vật hoá" của các đối tượng từ cơ sở dữ liệu, do đó bạn không cần phải viết mã đó, duy trì mối quan hệ giữa chúng, vv Đó là một cách làm việc hoàn chỉnh hơn, nhưng hoàn toàn khác với cơ sở dữ liệu.

Bạn cần cân nhắc xem trước tiên bạn có chuyển sang kiểu truy cập dữ liệu ORM không. Từ đó bạn có thể quyết định nếu EF hoặc một trong nhiều ORM khác trong không gian .NET sẽ phù hợp với nhu cầu của bạn nhất.

Có rất nhiều nhà cung cấp có sẵn cho EF (xem câu trả lời của Devart cho danh sách) nhưng tất cả đều là chi phí bên ngoài/phụ. Người duy nhất trong hộp là cho Sql Server. Mặc dù tôi sẽ thêm rằng DAAB không thực sự hoàn toàn bao gồm "độc lập cơ sở dữ liệu" điều - nếu bạn có bất kỳ SQL thực tế trong các cuộc gọi DAAB của bạn, nó không giúp bạn với sự khác biệt trong phương ngữ SQL. EF sẽ.

Answer 3

Có lợi thế nào để chuyển sang Khung thực thể không?

Thường nhanh hơn để hoàn thành công việc truy cập dữ liệu của bạn. LINQ cú pháp là rất tốt và có thể truy vấn sql.

EF có giữ các tiêu chí "Cơ sở dữ liệu" không phụ thuộc của chúng tôi không?

Không hỗ trợ 3rd party. Mặc dù tôi đã không chạy vào BẤT CỨ phát triển mà trên thực tế đã có một ứng dụng hoạt động và chuyển đổi công nghệ cơ sở dữ liệu đến hoặc từ sql.

Hoặc chúng ta có nên tiếp tục triển khai EntLib DAAB nhưng nâng cấp lên phiên bản mới nhất (5.0) không?

DAAB thật tuyệt vời !! Tôi đã viết một mã số generator cho nó .. Ngoài ra sau khi thực hiện EF cho một cơ sở dữ liệu lớn với lược đồ quan hệ VERY POOR tôi thấy rằng thuật sĩ 'EF' đã mất nhiều thời gian để cập nhật, 3 phút cho 110 sql bảng (khoảng). Đó là quá chậm và tôi đã trở lại DAAB ... Tôi sẽ nói con đường phía trước là EF tuy nhiên. Tôi chỉ cố gắng sử dụng nó với các thủ tục được lưu trữ và Không theo dõi cho tốt nhất performance. Một điều khác cần lưu ý với EF là hợp nhất các xung đột khi hai người cập nhật riêng biệt các quyền lợi. Nó có thể gây nhầm lẫn.