ORM vẫn là một anti-pattern sao?

• ORM (object-relational mapper) thường bị chỉ trích là một phản mẫu trong phát triển phần mềm.
• Tuy nhiên, những chỉ trích này bị phóng đại, và ORM cũng như các công cụ phần mềm khác không hề xấu về bản chất.
• Vấn đề thực sự của ORM thường nằm ở việc bị dùng sai hoặc bị hiểu sai.
• ORM và cơ sở dữ liệu quan hệ vận hành theo các mô hình khác nhau, nên có thể phát sinh những thách thức trong việc mô hình hóa dữ liệu và các mối quan hệ.
• ORM vi phạm nguyên tắc trách nhiệm đơn lẻ (SRP) và nguyên tắc phân tách mối quan tâm (SOC), nhưng những chỉ trích này không hẳn là vấn đề mang tính quyết định.
• Vấn đề thực sự của ORM nằm ở hiệu quả và khả năng quan sát.
• Nếu không được sử dụng đúng cách, ORM có thể kém hiệu quả, nhưng nó cũng có các tính năng giúp tối ưu hóa truy vấn và cải thiện hiệu năng.
• Vấn đề N+1, khi ORM phải qua lại với cơ sở dữ liệu nhiều lần, có thể được giảm nhẹ bằng cách dùng data loader.
• Vấn đề lớn nhất của ORM là khả năng quan sát và gỡ lỗi. Nó có thể không đưa ra thông báo lỗi rõ ràng hoặc khiến việc hiểu và khắc phục vấn đề trở nên khó khăn.
• Khi được sử dụng đúng cách, ORM có thể hiệu quả tương đương SQL thuần, nhưng nhà phát triển cần tận dụng các tính năng và các cơ chế tương ứng với SQL gốc.
• Với một số truy vấn phức tạp hoặc có vấn đề, có thể cần chuyển sang truy vấn SQL thuần.
• Nhìn chung, ORM không xấu về bản chất, nhưng cần được sử dụng cẩn trọng và có hiểu biết để tránh các vấn đề tiềm ẩn.

[GN⁺]

Ý kiến trên Hacker News

• Những giới hạn và nhược điểm của ORM, chẳng hạn như không thể dùng cơ sở dữ liệu khác và vẫn đòi hỏi kiến thức về SQL, đang bị chỉ trích.
• Xây dựng tầng dữ liệu theo từng truy vấn, bằng cách nội suy chuỗi và theo phong cách gần với JDBC thuần, được xem là cách tiếp cận tốt hơn.
• ORM thường chỉ giới hạn ở việc ánh xạ bảng và view cơ bản, đồng thời bỏ qua các tính năng và khả năng nâng cao của SQL.
• Có hai loại ORM: loại dựa trên domain model và loại tạo domain model từ cơ sở dữ liệu có sẵn.
• Các ORM như jOOQ và Hibernate có cách triển khai và tính năng khác nhau, nên mỗi loại được dùng cho mục đích khác nhau.
• ORM có thể hữu ích trong các ứng dụng phức tạp với nhiều bảng và quan hệ khóa ngoại phù hợp.
• Dùng SQL thuần trong string literal được xem là một giải pháp thay thế cho ORM; cũng có thể dùng các công cụ tạo query wrapper.
• ORM thực dụng, không cố giấu mọi thứ trong một gói hoặc áp đặt ngôn ngữ truy vấn riêng, được ưa chuộng hơn.
• SQLAlchemy được khen ngợi vì cung cấp một lớp truy vấn tiện lợi mà không tái tạo lại SQL.
• Nếu không dùng ORM, lập trình viên sẽ phải tự viết và duy trì giao diện cơ sở dữ liệu của riêng mình, điều này có thể dẫn đến lỗi và lỗ hổng bảo mật.
• Những chỉ trích cho rằng ORM vi phạm các nguyên tắc SOLID được xem là sự xung đột giữa giáo điều học thuật và phát triển phần mềm thực tế.
• Việc thiếu kinh nghiệm hoặc bị ảnh hưởng bởi các thực hành mang tính học thuật có thể gây ra vấn đề và làm vượt ngân sách.