ActiveRecord에 대한 몇 가지 유효한 비판이 있습니다. 항상 그렇듯이 Bob 아저씨 는 그것을 완벽하게 요약합니다 .
Active Record의 문제점은이 두 가지 매우 다른 스타일의 프로그래밍에 대해 혼동을 일으킨다는 것입니다. 데이터베이스 테이블은 데이터 구조입니다. 데이터가 노출되었으며 동작이 없습니다. 그러나 활성 레코드는 개체 인 것 같습니다. "숨겨진"데이터와 노출 된 동작이 있습니다. 데이터가 실제로 숨겨져 있지 않기 때문에“숨겨진”이라는 단어를 따옴표로 묶었습니다. 거의 모든 ActiveRecord 파생 상품은 접근 자와 변경자를 통해 데이터베이스 열을 내 보냅니다. 실제로, 활성 레코드는 데이터 구조처럼 사용됩니다.
반면에 많은 사람들이 비즈니스 규칙 방법을 Active Record 수업에 넣습니다. 그것들은 객체처럼 보입니다. 이것은 딜레마로 이어집니다. 액티브 레코드는 실제로 어느쪽에 있습니까? 대상입니까? 아니면 데이터 구조입니까?
Wikipedia는 테스트 가능성 문제 에서 비판을 요약합니다 .
OOP에서 캡슐화 개념은 종종 우려 분리 개념과 상충됩니다. 일반적으로, 분리를 선호하는 패턴은 분리 된 단위 테스트에 더 적합하지만 캡슐화를 선호하는 패턴은 API를 사용하기가 더 쉽습니다. Active Record는 데이터베이스없이 테스트하기가 어려운 시점까지 캡슐화를 선호합니다.
Ruby on Rails 구현을 위해 Gavin King은 다음과 같이 씁니다 .
이 시점에서 대부분의 개발자는 음, 생각하고 있습니다. 그렇다면 내 코드를 보면 회사가 어떤 속성을 가지고 있는지 어떻게 알 수 있습니까? IDE는 어떻게 자동 완성 할 수 있습니까? 물론, Rails 사람들은이 질문에 대한 빠른 답변을 얻을 것입니다. 데이터베이스 클라이언트를 시작하고 데이터베이스를 살펴보십시오!. 그런 다음 ActiveRecord의 자동 대문자 및 복수 규칙을 완벽하게 알고 있다고 가정하면 자체 Company 클래스의 속성 이름 을 추측 하여 수동으로 입력 할 수 있습니다.
또한 Ruby on Rails 구현에서 John Januszczak은 다음과 같이 씁니다 .
문제 # 1 : 정적 방법
...
어떤 사람들은 정적 메소드를 사용하는 것이 절차 적 프로그래밍에 불과하므로 객체 지향 디자인이 좋지 않다고 말합니다. 다른 사람들은 정적 메소드가 테스트 가능성으로 인한 사망이라고 말합니다.
문제 # 2 : 글로벌 구성 설정
...
따라서 필자의 예제에서 Account 클래스와 Account 인스턴스에 대한 종속성 주입 은 없습니다 . 우리 모두가 지금 알아야 할 것처럼, 물건을 찾는 것은 매우, 매우 나쁩니다!
ActiveRecord 및 ORM이 일반적으로 반 패턴으로 간주되는 이유에 대한 몇 가지 추가 자료 :
ActiveRecord는 항상 매우 유용한 안티 패턴 처럼 느껴졌 지만 SRP와 종속성 반전 원칙에 위배된다는 데 동의합니다.