액티브 레코드 패턴

소프트웨어 엔지니어링 에서 활성 레코드 패턴은 아키텍처 패턴이다. 소프트웨어 에서는 메모리 내 객체 데이터를 관계형 데이터베이스에 저장한다. Martin Fowler 가 2003년 저서 Patterns of Enterprise Application Architecture 에서 명명했다. 이 패턴을 준수하는 객체의 인터페이스에는 삽입, 업데이트 및 삭제와 같은 함수와 기본 데이터베이스 테이블의 열에 거의 직접적으로 해당하는 속성이 포함된다.

액티브 레코드 패턴은 데이터베이스의 데이터에 액세스하는 접근 방식이다. 데이터베이스 테이블 또는 뷰는 클래스 로 래핑된다. 따라서 객체 인스턴스는 테이블의 단일 행에 연결된다. 개체를 만든 후 저장할 때 새 행이 테이블에 추가된다. 로드된 모든 객체는 데이터베이스에서 해당 정보를 가져온다. 객체가 업데이트되면 테이블의 해당 행도 업데이트된다. 래퍼 클래스는 테이블 또는 뷰의 각 열에 대한 접근자 메서드 또는 속성을 구현한다.

이 패턴은 일반적으로 객체 지속성 도구 및 ORM( 객체 관계형 매핑 )에서 사용된다. 일반적으로 외래 키 관계는 속성을 통해 적절한 유형의 객체 인스턴스로 노출된다.

구현

이 개념의 구현은 다양한 프로그래밍 환경을 위한 많은 프레임워크 에서 찾을 수 있다. 예를 들어 데이터베이스에 열 name (문자열 유형) 및 price (숫자 유형)이 있는 테이블 parts 있고 Active Record 패턴이 Part 클래스에 구현된 경우

part = new Part()
part.name = "Sample part"
part.price = 123.45
part.save()

주어진 값으로 parts 테이블에 새 행을 생성하며 대략 SQL 명령과 동일하다. 반대로 클래스를 사용하여 데이터베이스를 질의할 수 있다.

b = Part.find_first("name", "gearbox")

그러면 name 열의 값이 "기어박스"인 parts 테이블의 첫 번째 일치 행을 기반으로 새 Part 객체를 찾는다. 사용되는 SQL 명령은 데이터베이스의 SQL 구현 세부 정보에 따라 다음과 유사할 수 있다.

비판

테스트 가능성

활성 레코드 패턴을 사용할 때 데이터베이스 상호 작용과 애플리케이션 논리의 결합으로 인해 데이터베이스 없이 활성 레코드 객체를 단위 테스트하는 것이 어려워진다. 활성 레코드 패턴의 테스트 가능성에 대한 이러한 부정적인 영향은 모킹 또는 종속성 주입 프레임워크를 사용하여 실제 데이터 계층을 시뮬레이션된 계층으로 대체하여 줄일 수 있다.

단일 책임 원칙 및 관심사 분리

활성 레코드 패턴에 대한 또 다른 비판은 데이터베이스 상호 작용과 애플리케이션 논리의 강력한 결합으로 인해 활성 레코드 개체가 이러한 관행을 적절하게 다루는 다중 계층 아키텍처 와 달리 단일 책임 원칙 및 관심사 분리를 따르지 않는다는 것이다.   이 때문에 활성 레코드 패턴은 CRUD 기능이 있는 모든 형식이 데이터인 간단한 응용 프로그램이나 아키텍처의 한 부분으로 가장 적합하고 가장 자주 사용된다.  일반적으로 데이터 접근을 위해 자주 사용되며, 이러한 이유 때문에 여러 ORM이 활성 레코드 패턴을 구현한다.

분산 시스템

레코드 기반 패턴은 특히 동시성이 불가능한 경우(예: 오프라인) 분산 시스템에서 제대로 작동하지 않는다. 즉, 두 업데이트 모두 올바른 필드 하나를 가질 수 있지만 두 레코드 중 하나만 이길 수 있다.

참고

• Business object
• CRUD
• Data mapper pattern
• Object–relational mapping