Active Record

Active Record 패턴이란?

Active Record 패턴은 객체 지향 프로그래밍에서 데이터베이스 테이블과 클래스 간의 매핑을 간소화하는 ORM(Object Relational Mapping) 패턴입니다. 각 데이터베이스 테이블은 하나의 클래스에 대응되며, 해당 클래스의 인스턴스는 테이블의 한 행(row)에 대응됩니다. Active Record 패턴을 사용하면 객체가 자신이 속한 테이블의 데이터를 직접 처리하며, CRUD(Create, Read, Update, Delete) 작업을 간편하게 수행할 수 있습니다.

Active Record 패턴의 특징

데이터베이스와 클래스의 직접 매핑
각 클래스는 데이터베이스의 테이블과 직접적으로 매핑됩니다. 클래스의 속성은 테이블의 컬럼에 대응되며, 클래스 인스턴스는 테이블의 행에 대응됩니다. 이를 통해 데이터베이스의 레코드를 객체로 다룰 수 있습니다. 간단한 CRUD 작업
Active Record 패턴을 사용하면 데이터베이스의 기본적인 CRUD 작업을 매우 간단하게 구현할 수 있습니다. 데이터베이스의 레코드를 조작하는 SQL 쿼리 대신 객체 지향적으로 데이터를 처리할 수 있습니다. 비즈니스 로직 포함
객체는 데이터베이스와 상호작용하는 동시에 비즈니스 로직을 포함할 수 있습니다. 데이터를 처리하는 메서드를 클래스 내부에 포함시키는 방식으로, 코드의 응집도를 높일 수 있습니다.

Active Record 패턴 적용

Active Record 패턴의 필요성

Active Record 패턴은 객체 지향 프로그래밍에서 데이터베이스와 객체 간의 매핑을 간소화하기 위해 필요합니다. 이 패턴을 적용하면 데이터베이스 접근 로직을 간편하게 처리할 수 있으며, 비즈니스 로직과 데이터 접근을 통합할 수 있습니다. 특히, 작은 규모의 애플리케이션에서는 간결한 CRUD 처리가 가능해 개발 생산성을 높이는 데 기여합니다.

잘못된 처리

public class BookService
{
    public void CreateBook(string title, string author)
    {
        // 데이터베이스 접근 로직과 비즈니스 로직이 섞여 있음
        Console.WriteLine("Inserting book into database...");
    }
    public Book GetBook(int id)
    {
        // SQL 쿼리를 사용한 데이터베이스 접근 로직
        Console.WriteLine($"Fetching book with ID: {id}");
        return new Book { Id = id, Title = "Sample Title", Author = "Sample Author" };
    }
    public void DeleteBook(int id)
    {
        // 데이터베이스 삭제 로직과 비즈니스 로직이 결합
        Console.WriteLine($"Deleting book with ID: {id}");
    }
}

문제점

SQL 쿼리와 비즈니스 로직의 결합
비즈니스 로직과 데이터베이스 접근 로직이 혼합되어 있어 유지보수가 어렵고, 데이터베이스 변경 시 수정할 코드가 많습니다. 재사용성 부족
데이터 접근 로직이 여러 곳에 흩어져 있어 코드의 재사용이 어렵고, 각 서비스에서 같은 코드가 중복될 가능성이 있습니다. 확장성 저하
데이터베이스 스키마 변경 시 여러 코드에서 수정이 필요해 확장성이 낮아집니다.

Active Record 패턴 적용 예시

public class Book
{
    public int Id { get; set; }
    public string Title { get; set; }
    public string Author { get; set; }
    public static Book Find(int id)
    {
        // 데이터베이스에서 책을 가져오는 메서드
        return new Book { Id = id, Title = "Sample Title", Author = "Sample Author" };
    }
    public void Save()
    {
        // 데이터베이스에 저장 (새로운 레코드 삽입 또는 기존 레코드 업데이트)
        Console.WriteLine($"Saving book: {Title} by {Author}");
    }
    public void Delete()
    {
        // 데이터베이스에서 책 레코드를 삭제
        Console.WriteLine($"Deleting book: {Title}");
    }
}

개선사항

데이터 접근 로직과 비즈니스 로직의 분리
잘못된 처리에서는 데이터 접근 로직과 비즈니스 로직이 섞여 있었으나, Active Record 패턴을 적용함으로써 데이터 접근이 Book 클래스 내에 캡슐화됩니다. 이를 통해 데이터베이스 작업과 비즈니스 로직이 명확히 분리되고, 코드의 일관성이 향상됩니다. 중복 코드 제거
CRUD 작업이 Book 클래스 내에 통합되므로, 각 서비스에서 데이터베이스 접근 로직이 중복되지 않고 간결하게 관리됩니다. 유지보수성 향상
데이터베이스 스키마가 변경되더라도 Active Record 클래스만 수정하면 되기 때문에, 코드의 유지보수성이 향상됩니다.

Active Record 패턴 구성 요소

Entity 클래스
Book과 같은 엔터티 클래스는 데이터베이스 테이블의 각 레코드를 표현하며, 데이터를 포함하고 데이터 처리를 위한 메서드도 제공합니다. CRUD 메서드
엔터티 클래스는 데이터베이스와 상호작용하는 Create, Read, Update, Delete 메서드를 포함하여 직접적인 데이터 조작을 가능하게 합니다. 비즈니스 로직
Active Record 클래스는 비즈니스 로직도 포함할 수 있으며, 데이터베이스와의 상호작용을 객체 내에서 처리합니다.

장점

간결한 CRUD 처리
데이터베이스 작업을 위한 별도의 DAO 클래스나 레이어가 필요 없으며, CRUD 작업을 객체 내에서 바로 처리할 수 있습니다. 비즈니스 로직과 데이터 접근 통합
비즈니스 로직을 포함한 클래스가 데이터베이스와 직접 상호작용할 수 있어, 객체 중심의 설계를 지원합니다. 이를 통해 클래스 자체에서 비즈니스 로직과 데이터 처리가 동시에 이루어질 수 있습니다. 데이터 접근 로직의 재사용
데이터베이스와 상호작용하는 로직이 객체 내에 캡슐화되어 재사용성이 높아집니다. 동일한 데이터 접근 로직을 여러 클래스에서 쉽게 활용할 수 있습니다.

단점

비즈니스 로직과 데이터베이스 결합
비즈니스 로직과 데이터베이스 접근 로직이 동일한 클래스에 포함되기 때문에, 로직이 복잡해지거나 데이터베이스에 강하게 의존하게 됩니다. 이는 애플리케이션의 유연성을 저하시킬 수 있습니다. 대규모 시스템에서의 확장성 한계
대규모 애플리케이션에서는 각 클래스가 자신의 데이터베이스 접근 로직을 가지고 있으면, 코드가 중복되거나 복잡해질 수 있습니다. 이는 유지보수를 어렵게 하고, 성능 저하를 일으킬 수 있습니다. 테스트의 어려움
Active Record 패턴은 데이터베이스와 직접 상호작용하므로, 유닛 테스트를 작성하기 어려울 수 있습니다. Mocking을 통한 테스트가 복잡해지며, 독립적인 테스트 환경을 구성하기 힘듭니다.

맺음말

Active Record 패턴은 간단한 데이터 접근 및 조작이 필요한 애플리케이션에서 매우 유용한 패턴입니다. 데이터베이스와 객체 간의 매핑을 쉽게 처리할 수 있고, CRUD 작업을 엔터티 클래스 내에서 직접적으로 수행할 수 있어 코드가 간결해집니다. 특히, 작은 규모의 프로젝트에서는 개발 생산성을 높이고 유지보수성을 향상시키는 장점이 있습니다.

심화 학습

Active Record 패턴과 Domain-Driven Design (DDD) 간의 충돌

Active Record 패턴은 간단한 데이터 접근 패턴으로, 객체가 자신을 데이터베이스에 저장하거나 업데이트하는 기능을 직접 포함하고 있습니다. 반면, Domain-Driven Design (DDD)에서는 엔터티가 비즈니스 로직을 중심으로 설계되며, 데이터 접근은 별도의 레이어(Repository)에서 관리되도록 설계됩니다. 이로 인해, Active Record 패턴과 DDD는 충돌하는 철학을 가지고 있습니다.

• Active Record의 장점: 간단한 CRUD 작업과 데이터베이스와의 상호작용을 빠르게 구현할 수 있습니다.
• DDD 관점의 단점: 비즈니스 로직과 데이터 접근 로직이 결합되어, 복잡한 비즈니스 도메인에서는 테스트와 유지보수가 어려워질 수 있습니다.

Active Record 패턴의 트랜잭션 관리

Active Record 패턴은 엔터티가 직접 데이터베이스와 상호작용하므로, 트랜잭션 관리에 주의가 필요합니다. 대규모 애플리케이션에서는 트랜잭션 범위를 명확히 정의하고 관리하는 것이 중요한데, Active Record 패턴은 개별 엔터티에 의존하기 때문에 트랜잭션 관리가 불명확해질 수 있습니다.

해결 방법

서비스 레이어에서 트랜잭션 관리 Active Record 패턴을 사용하더라도, 서비스 레이어에서 트랜잭션을 관리하여 여러 엔터티가 일관된 트랜잭션 내에서 동작하도록 할 수 있습니다. Unit of Work와의 결합 Active Record와 Unit of Work 패턴을 함께 사용하면, 여러 엔터티 작업을 트랜잭션으로 묶어 일관성 있는 데이터 처리가 가능합니다.

성능 최적화와 N+1 문제

Active Record 패턴을 사용할 때, 관련 엔터티를 함께 로드하지 않으면 N+1 문제가 발생할 수 있습니다. 이는 기본적으로 각 엔터티에 대해 데이터베이스 쿼리를 실행하는 방식 때문에, 연관된 데이터를 로드하는 과정에서 많은 수의 추가 쿼리가 실행되는 문제입니다.

해결 방법:

Eager Loading 사용 처음부터 필요한 모든 데이터를 한 번에 로드하도록 설정하여 N+1 문제를 방지할 수 있습니다. Lazy Loading 사용 연관된 데이터를 필요할 때만 로드하도록 하여, 불필요한 데이터베이스 접근을 줄일 수 있습니다.

Active Record와 복잡한 쿼리 처리

Active Record 패턴은 기본적으로 간단한 CRUD 작업에 적합하지만, 복잡한 쿼리를 작성하고 실행하는 데는 제한이 있을 수 있습니다. 특히 복잡한 JOIN, 서브쿼리 또는 집계 함수가 필요할 때는 Active Record의 한계가 드러납니다.

해결 방법

Query Object 패턴 복잡한 쿼리를 Active Record 엔터티 외부에서 처리할 수 있도록 Query Object 패턴을 도입하여, 쿼리 로직을 분리하고 관리할 수 있습니다. Raw SQL 사용 Active Record 엔터티 내에서 Raw SQL을 사용하여 복잡한 쿼리를 직접 실행할 수 있습니다. 이 방법은 성능 최적화와 복잡한 쿼리 처리에 유용할 수 있습니다.

테스트 용이성 및 Mocking 전략

Active Record 패턴은 엔터티가 데이터베이스와 직접 상호작용하기 때문에, 단위 테스트가 어려울 수 있습니다. 특히, 실제 데이터베이스 연결 없이 비즈니스 로직만을 테스트하려면 별도의 Mocking 전략이 필요합니다.

해결 방법

Mocking 프레임워크 사용 엔터티의 데이터베이스 상호작용을 Mocking하여, 실제 데이터베이스 연결 없이 엔터티 로직을 테스트할 수 있습니다. In-Memory Database 사용 테스트 환경에서 In-Memory Database를 사용하여, Active Record 엔터티의 실제 동작을 검증하면서도 빠르고 독립적인 테스트가 가능합니다.

Active Record와 대규모 시스템 확장성

대규모 시스템에서는 Active Record 패턴의 확장성에 한계가 있을 수 있습니다. 엔터티가 데이터베이스와 직접 상호작용하는 구조는, 엔터티의 책임이 과도하게 커질 수 있고, 비즈니스 로직과 데이터베이스 로직이 복잡하게 얽힐 수 있습니다. 이러한 문제는 확장성과 유지보수성에 영향을 미칩니다.

해결 방법:

Repository 패턴 도입 Active Record 패턴을 Repository 패턴과 결합하여, 데이터 접근을 분리하고 확장성을 높일 수 있습니다. CQRS 패턴 읽기와 쓰기 작업을 분리하여, 성능을 최적화하고 확장성을 고려한 구조를 설계할 수 있습니다.

Buy me a coffee