Mẫu ActiveRecord có tuân theo / khuyến khích các nguyên tắc thiết kế RẮN không?

Tôi quan tâm đến việc liệu mẫu ActiveRecord, nổi tiếng từ Ruby on Rails, có khuyến khích hoặc không khuyến khích việc sử dụng các nguyên tắc thiết kế RẮN .

Ví dụ, đối với tôi, các đối tượng ActiveRecord đều chứa logic miền và logic bền vững, vi phạm Trách nhiệm đơn lẻ.

Có một số lời chỉ trích hợp lệ trên ActiveRecord. Như mọi khi, chú Bob tổng hợp nó một cách hoàn hảo :

Vấn đề tôi gặp phải với Active Record là nó tạo ra sự nhầm lẫn về hai phong cách lập trình rất khác nhau này. Một bảng cơ sở dữ liệu là một cấu trúc dữ liệu. Nó đã tiếp xúc với dữ liệu và không có hành vi. Nhưng một bản ghi hoạt động dường như là một đối tượng. Nó có dữ liệu ẩn giấu dữ liệu và hành vi tiếp xúc. Tôi đặt từ "ẩn" ẩn trong dấu ngoặc kép vì trên thực tế, dữ liệu không bị ẩn. Hầu như tất cả các công cụ phái sinh ActiveRecord đều xuất các cột cơ sở dữ liệu thông qua các bộ truy cập và bộ biến đổi. Thật vậy, Active Record có nghĩa là được sử dụng như một cấu trúc dữ liệu.

Mặt khác, nhiều người đưa các phương thức quy tắc kinh doanh vào các lớp Bản ghi hoạt động của họ; mà làm cho chúng dường như là đối tượng. Điều này dẫn đến một vấn đề nan giải. Active Record thực sự rơi ở phía nào của dòng? Nó là một đối tượng? Hay là một cấu trúc dữ liệu?

Wikipedia tổng hợp những lời chỉ trích trong một mối quan tâm kiểm tra :

Trong OOP, khái niệm đóng gói thường mâu thuẫn với khái niệm phân tách mối quan tâm. Nói chung, các mẫu ưu tiên phân tách mối quan tâm phù hợp hơn với các thử nghiệm đơn vị bị cô lập trong khi các mẫu ủng hộ đóng gói có sử dụng API dễ dàng hơn. Active Record rất thích đóng gói đến mức kiểm tra mà không có cơ sở dữ liệu là khá khó khăn.

Cụ thể đối với việc triển khai Ruby on Rails, Gavin King viết (nhấn mạnh của tôi):

Tại thời điểm này, hầu hết các nhà phát triển đều nghĩ um, ok, vậy làm thế quái nào tôi có thể biết những thuộc tính nào mà Công ty có bằng cách xem mã của tôi? Và làm thế nào IDE của tôi có thể tự động hoàn thành chúng? Tất nhiên, những người Rails có câu trả lời nhanh cho câu hỏi này Oh, chỉ cần kích hoạt ứng dụng khách cơ sở dữ liệu của bạn và tìm trong cơ sở dữ liệu!. Sau đó, giả sử rằng bạn biết các quy tắc viết hoa và số nhiều tự động hóa của ActiveRecord / một cách hoàn hảo /, bạn sẽ có thể đoán tên của các thuộc tính của lớp Công ty của riêng bạn và nhập chúng theo cách thủ công.

Cũng về việc triển khai Ruby on Rails, John Januszczak viết (nhấn mạnh của tôi):

VẤN ĐỀ # 1: PHƯƠNG PHÁP TÌNH TRẠNG

...

Một số người sẽ nói rằng sử dụng các phương thức tĩnh chỉ đơn giản là số tiền cho lập trình thủ tục, và do đó là thiết kế hướng đối tượng kém. Những người khác sẽ nói phương pháp tĩnh là cái chết đối với khả năng kiểm tra.

VẤN ĐỀ # 2: CÀI ĐẶT CẤU HÌNH TOÀN CẦU

...

Do đó, không có nội dung phụ thuộc vào lớp Tài khoản trong ví dụ của tôi và phần mở rộng, trên các phiên bản Tài khoản. Như tất cả chúng ta nên biết bây giờ, tìm kiếm mọi thứ là rất, rất xấu!

Một vài tài nguyên nữa về lý do tại sao ActiveRecord và ORM thường được coi là một mô hình chống:

• Mô hình miền Rails tách rời Activerecord trên StackOverflow,
• ORM là một mô hình chống
• Hiệp hội bẩn với ActiveRecord
• Vấn đề # 23: Nguyên tắc thiết kế RẮN về thực hành Ruby

ActiveRecord luôn cảm thấy giống như một mô hình chống cực kỳ hữu ích , nhưng tôi đồng ý rằng nó đi ngược lại SRP và bổ sung rằng nó đi ngược lại nguyên tắc đảo ngược phụ thuộc.

(Tôi giả sử rằng lớp ActiveRecord được triển khai mà không có bất kỳ khả năng tiêm phụ thuộc nào).

Từ kinh nghiệm cá nhân tôi có thể nói rằng mẫu ActiveRecord trở thành một trở ngại lớn cho việc viết bài kiểm tra đơn vị. Sự kết hợp của lớp kiên trì và logic nghiệp vụ trong một "lớp ActiveRecord" duy nhất khiến bạn không thể viết các bài kiểm tra đơn vị (trừ khi bạn tái cấu trúc trước). Do đó, lựa chọn duy nhất là viết các bài kiểm tra tích hợp; và điều đó không hiệu quả như các bài kiểm tra đơn vị. Điều này trở thành một vấn đề lớn đặc biệt là nếu bạn tiếp quản một dự án có nhiều lớp ActiveRecord; nó mang lại các bài kiểm tra tích hợp rất phức tạp, khó duy trì.

Vì vậy, ActiveRecord chống lại SRP khá nhiều và gây ra một số vấn đề đau đầu về bảo trì; nó dường như lấy đi sức mạnh để viết bài kiểm tra đơn vị.