활성 레코드 패턴

소프트웨어 엔지니어링에서 액티브한 레코드 패턴은 일부 사용자에게는 아키텍처 패턴으로 간주되며 일부 사용자에게는 안티 패턴으로 간주됩니다.^[1]관계형 데이터베이스에 메모리 내 객체 데이터를 저장하는 소프트웨어에서 찾을 수 있습니다.Martin Fowler가 2003년 저서 "Patterns of Enterprise Application Architecture"^[2][3]에서 명명했습니다.이 패턴에 적합한 개체의 인터페이스에는 삽입, 업데이트 및 삭제와 같은 기능과 기본 데이터베이스 테이블의 열에 거의 직접 대응하는 속성이 포함됩니다.

활성 레코드 패턴은 데이터베이스 데이터에 액세스하는 방법입니다.데이터베이스 테이블 또는 뷰는 클래스로 래핑됩니다.따라서 오브젝트 인스턴스는 테이블 내의 단일 행에 연결됩니다.오브젝트 작성 후 저장 시 테이블에 새 행이 추가됩니다.로드된 개체는 데이터베이스에서 해당 정보를 가져옵니다.개체가 업데이트되면 테이블 내의 해당 행도 업데이트됩니다.래퍼 클래스는 테이블 또는 뷰의 각 열에 대해 접근자 메서드 또는 속성을 구현합니다.

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

실장

개념의 구현은 많은 프로그래밍 환경의 다양한 프레임워크에서 찾을 수 있습니다.예를 들어 테이블이 있는 경우parts컬럼이 있는 데이터베이스에서name(문자열 유형) 및price(번호 타입), Active Record 패턴이 클래스에 실장됩니다.Part, 의사 코드

일부 = 신규 일부() 일부.이름. = "샘플 부품" 일부.가격. = 123.45 일부.절약하다() 

에 새로운 행을 만듭니다.parts지정된 값이 포함된 테이블로 SQL 명령과 거의 동일합니다.

삽입 안으로 부품. (이름., 가격.) 가치 ('샘플 부품', 123.45); 

반대로 클래스를 사용하여 데이터베이스를 조회할 수 있습니다.

b = 일부.find_first(처음("이름, "실패") 

이것은 새로운 것을 찾을 것이다.Part에서의 첫 번째 일치하는 행을 기반으로 하는 객체parts그 테이블name컬럼의 값은 "displicate"입니다.데이터베이스의 SQL 구현 세부 정보에 따라 사용되는 SQL 명령은 다음과 비슷할 수 있습니다.

선택한다. * 부터 부품. 어디에 이름. = '실패' 제한. 1; -- MySQL 또는 PostgreSQL 

비판

테스트 가능성

액티브 레코드 패턴을 사용할 때는 데이터베이스 상호작용과 애플리케이션 로직이 결합되기 때문에 데이터베이스가 없는 액티브 레코드 오브젝트의 유닛 테스트가 어려워집니다.활성 레코드 패턴의 테스트 가능성에 대한 이러한 부정적인 영향은 실제 데이터 계층을 시뮬레이션된 계층으로 대체하기 위해 조롱 또는 의존성 주입 프레임워크를 사용함으로써 줄일 수 있습니다.

단일 책임 원칙 및 문제 분리

활성 레코드 패턴의 또 다른 비평하는 제대로 이러한 관행을 다루multitier 건축에 반대하는 것은, 또한 데이터베이스 상호 작용과 응용 프로그램 논리의 강력한 결합으로 인해, 적극적 레코드 개체들을 우려하여 단일 책임 원칙과 이별을 따르지 않는다는 것이다.[표창 필요한][해명 필요한]따라서 액티브 레코드 패턴은 최적이며, CRUD 기능을 갖춘 모든 폼오버 데이터 또는 아키텍처의 ^{[citation needed]}일부로서만 사용되는 단순한 애플리케이션에서 가장 많이 사용됩니다.일반적으로 이 부분은 데이터 액세스이며, 여러 ORM이 액티브한 레코드 패턴을 구현하는 이유이기도 합니다.

분산 시스템

레코드 기반 패턴은 특히 동시성이 불가능한(오프라인 등) 분산 시스템에서 제대로 작동하지 않습니다. 즉, 두 업데이트 모두 하나의 필드가 올바르지만 ^{[clarification needed]}두 레코드 중 하나만 획득할 수 있습니다.

「 」를 참조해 주세요.

• 비즈니스 오브젝트
• CRUD – 컴퓨터 데이터베이스의 기본 조작
• 데이터 매퍼 패턴
• 오브젝트-관계매핑– 프로그래밍

레퍼런스