So sánh Dapper với Entity Framework Core ngoài vấn đề hiệu suất

Dapper vs Entity Framework

Hãy để chúng tôi bắt đầu với câu trả lời mà hầu hết mọi người tìm kiếm khi đưa ra câu hỏi này. Entity Framework có thực sự tệ như vậy không? Và câu trả lời là phức tạp. Khi nói đến hiệu suất…

Hãy xem điểm chuẩn này nói lên điều gì:

Về cơ bản, dapper là lựa chọn cao cấp hơn trong trường hợp hiệu suất. Tuy nhiên, có rất nhiều thứ liên quan đến phát triển phần mềm hơn là hiệu suất.

Tốc độ phát triển và tính linh hoạt

Vì vậy, hãy nói về những điều quan trọng khác khi nói đến việc chọn một phương pháp truy cập vào DB của bạn. Tốc độ phát triển là quan trọng, nhưng nó phụ thuộc nhiều vào nhóm của bạn, nếu nhóm của bạn đã quen với mọi thông báo trước, khung thực thể đó có thể cung cấp cho bạn cả trong quá trình phát triển và sản xuất, thì EF có thể là lựa chọn tốt hơn.

Tuy nhiên, hãy lưu ý rằng EF Core khác với EF 6, đó là thứ mà hầu hết các nhà phát triển dày dạn kinh nghiệm sẽ làm việc trong môi trường sản xuất. Có những cảnh báo mới đối với EF cần phải được xem xét, chẳng hạn như điều gì thực sự xảy ra khi bạn sử dụng chức năng “Bao gồm” để thực hiện liên kết, khi nào bạn nên bật tải chậm và khi nào bạn nên tắt nó và cách xử lý Các đối tượng DB cơ bản hơn các bảng.

Trong trường hợp dapper, bạn không cần nhóm của mình phải có đầy đủ các chuyên gia dapper, đường cong học tập nhỏ và khá dễ dàng để tiếp thu với kiến ​​thức cơ bản về SQL và C #, một số kinh nghiệm ADO.NET sẽ không ảnh hưởng gì nhưng hoàn toàn không bắt buộc.

Tính linh hoạt là một trong những điểm tôi nghĩ dapper tỏa sáng nhất. Việc tích hợp các thủ tục được lưu trữ vào quy trình của bạn rất dễ dàng, tương tự với các chế độ xem. Một điều như vậy chắc chắn không phải là không thể với Entity Framework, nhưng nó khó hơn và bạn (và nhóm của bạn) cần phải nắm bắt được framework để làm điều này.

Để làm cho Dapper thực sự tỏa sáng, cần cân nhắc rằng bạn sẽ không sử dụng chỉ dapper trừ khi bạn muốn kiểm soát tuyệt đối. Để tăng tốc độ phát triển, bạn sẽ phải từ bỏ một số quyền kiểm soát, điều đó là đương nhiên. Đối với điều đó, có các phần mở rộng sẽ được đề cập bên dưới.

Phần mở rộng Dapper

Đúng vậy, dapper có các phần mở rộng, trên thực tế là 7 phần mở rộng và chúng đều làm những việc rất giống nhau, một số làm được nhiều hơn những phần khác.

Người dùng lần đầu sẽ gặp khó khăn trong việc phân biệt cái nào tốt hơn để sử dụng và những gì họ cung cấp. Dapper cơ bản rất dễ dàng, nhưng có rất nhiều câu hỏi đặt ra khi bạn muốn làm những thứ nâng cao hơn với ORM vi mô của mình. Bạn có thể đang sử dụng Postgres hoặc MySQL chứ không phải SQL Server, bạn có thể có một quy ước đặt tên kỳ lạ cho các đối tượng cơ sở dữ liệu của mình. Có thể bạn đã chấp nhận một số loại hệ thống kiểm soát phiên bản cơ sở dữ liệu chẳng hạn như di chuyển (có thể là di chuyển Entity Framwork hoặc một số nhà cung cấp khác) hoặc một công cụ để cập nhật lược đồ của bạn dựa trên các phép so sánh (như SSDT hoặc Postgres Compare).

Tiện ích mở rộng bạn chọn sử dụng sẽ tùy thuộc vào trường hợp sử dụng của bạn. Tôi thực sự thích Dapper Contrib vì nó đơn giản và vì nó là cái do chính những người tạo ra dapper tạo ra. Nhưng có thể không đủ khi sử dụng bất cứ thứ gì không phải là SQL Server nếu bạn muốn tùy chỉnh ánh xạ giữa các lớp thực thể với các bảng và trường cơ sở dữ liệu của bạn.

Bạn có thể tìm thấy một liên kết đến thêm thông tin để bạn có thể lựa chọn tại đây: https://dapper-tutorial.net/third-party-library

Code First so với Database First

Một vai trò lớn trong sự lựa chọn của bạn giữa Entity Framework và Dapper là cách tiếp cận ưa thích của bạn để quản lý thay đổi cơ sở dữ liệu. Bạn có muốn sử dụng Code First và mất quyền kiểm soát SQL được tạo không? hay bạn muốn sử dụng kiểu tiếp cận “Database First”?

Đây là một trong những yếu tố lớn nhất trong việc ra quyết định vì đây là nơi mọi thứ phân chia. Entity Framework Core trước tiên không thực sự hỗ trợ cơ sở dữ liệu. Có nhiều cách để buộc nó, chẳng hạn như sử dụng giàn giáo sau mỗi lần thay đổi cơ sở dữ liệu (hoặc thực hiện các thay đổi trong lớp DbContext thậm chí còn tệ hơn), nhưng các phương thức này rất cồng kềnh và rất dễ xảy ra lỗi.

Tôi nhớ đã cố gắng thực hiện điều này trong một dự án mà chúng tôi sử dụng EF Core 3. Tôi vừa viết một bản chuyển đổi bằng SQL thô, nhưng đáng buồn là nó không hoàn hảo. Tôi đã chạy quá trình di chuyển và sau đó chạy lệnh giàn giáo (scaffold command) gây ra khoảng 100 lỗi biên dịch. Thông thường, tôi sẽ chỉ quay lại, thay đổi quá trình di chuyển, xóa nó khỏi lịch sử và chạy lại, nhưng vì giàn giáo đã mang lại nhiều lỗi biên dịch nên tôi không thể chạy di chuyển nữa, vì ứng dụng của tôi không được biên dịch.

Các cuộc hội thảo như thế này cho tôi biết rằng công cụ của Entity Framework Core, mặc dù tuyệt vời trong trường hợp sử dụng của nó nhưng không phải để hỗ trợ các nhóm muốn kiểm soát SQL của họ.

Tôi phải lưu trữ tất cả các thay đổi của mình HOẶC thay đổi mọi thứ theo cách thủ công để biên dịch nó, sau đó thay đổi nó trở lại như cũ.

Có thể sử dụng cách tiếp cận “Code First” với Dapper. Bạn sẽ cần sử dụng một thư viện như FluentMigrator để làm cho nó hoạt động (vì cài đặt khung thực thể chỉ để di chuyển là không hợp lý), nhưng nó có thể hoạt động mà không cần quá nhiều công việc.

Những điều rút ra và ý kiến ​​của tôi

Đây là một chủ đề khó nói, vì có quá nhiều thứ để nói. Tôi có thể viết một bài tiếp theo vào lúc khác so sánh các phương pháp quản lý thay đổi cơ sở dữ liệu hoặc danh sách các phần mở rộng dapper được so sánh.

Nhưng bây giờ tôi sẽ để lại ý kiến ​​của tôi. Tôi nghĩ Dapper là lựa chọn tốt hơn khi bạn muốn kiểm soát cơ sở dữ liệu của mình. Được ghép nối với SSDT trong trường hợp SQL Server và Dapper Contrib hoặc Dapper. SimpleCRUD đó là một trong những cách dễ nhất để xử lý các ứng dụng nặng cơ sở dữ liệu phức tạp mà không mất quyền kiểm soát cơ sở dữ liệu của tôi hoặc phải gọi DBA của tôi để giải thích tại sao anh ta không thể sửa đổi cơ sở dữ liệu theo bất kỳ cách nào khác mà không thông qua di chuyển khung thực thể (entity framework migration).

Tham khảo: https://www.techgems.net/posts/2020-04-04/dapper-vs-entity-framework-core-going-beyond-just-performance

Viết một bình luận