티스토리 뷰

반응형

처음 개념을 잡는 것이 힘들었던 것 같습니다. Persistence의 개념을 먼저 잡고 시작하도록 하겠습니다.

Persistence

지속성(enceence性, )은 컴퓨터 과학에서, 그것을 만든 과정보다 더 오래 유지되는 시스템의 특성을 이야기합니다. 이는 실제로 상태를 컴퓨터 데이터 저장소의 데이터로 저장함으로써 달성됩니다. 그래서, 데이터 저장소와 관련된 것을 persistence라고 생각하시면 좋을 것 같습니다.

 

데이터를 데이터 저장소를 이용해서 입력/출력을 하기위해서는 맵핑된 클래스가 필요합니다. 다음 DTO와 POCO는 그런 클래스를 이야기 합니다.

DTO

데이터 전송 오브젝트는 속성만 포함하는 경량 클래스이며, 클래스의 속성을 가져오고 설정할 수 있습니다.

DTO에는 동작 및 사용자 지정 논리가 포함되어 있지 않습니다.

    public class ClientDTO
    {
        public string FirstName { get; set; }
        public string LastName { get; set; }
        public string Email { get; set; }
        public string PhoneNo { get; set; }
        public string MobileNo { get; set; }
        public string County { get; set; }
        public string City { get; set; }
        public string Address { get; set; }
    }

POCO

POCO는 Plain Old CLR Object를 의미하며, POCO는 데이터, 유효성 검사 및 사용자 정의 또는 비즈니스 로직을 포함하지만 persistence 로직을 포함하지 않는데, 이는 데이터 저장 방법이나 데이터베이스를 이야기합니다. 그래서, POCO를 지속성 무시라고 이야기합니다.

Persistence ignorance

PI는 지속성 논리를 무시하는 것을 의미하며, 이것은 데이터 저장소와 관련된 논리를 사용하지 않는다는 것을 이야기합니다. 이것은 지속성 논리와 클래스를 분리해서 다양한 디바이스나 서비스를 통해서 지속성을 유지 할 수 있게 만들기 위한 방법입니다.

 

EF에서 POCO 클래스에 데이터 저장 또는 데이터 저장소에서 데이터 가져오기 등과 같은 데이터 저장소와 관련된 논리가 포함되어 있지 않다는 것을 알 수 있을 것입니다.

 

아래 POCO 클래스를 참고합니다.

    public class ClientPOCO
    {
        public string FirstName { get; set; }
        public string LastName { get; set; }
        public string Email { get; set; }
        public string PhoneNo { get; set; }
        public string MobileNo { get; set; }
        public string County { get; set; }
        public string City { get; set; }
        public string Address { get; set; }

        public string FullName()
        {
            return $"{FirstName} {LastName}";
        }

        public string FullAddress()
        {
            return $"{Address} {City} {County}";
        }
    }

DTO와 POCO 차이점

POCO는 속성과 메소드를 가질수 있지만, DTO는 속성만 가질 수 있습니다.

마이크로소프트의 PI 정리

지속성 무시(PI)는 동일한 비즈니스 모델을 여러 가지 방법으로 유지할 수 있도록 하여 애플리케이션에 추가적인 유연성을 제공하기 때문에 매우 중요합니다. 지속성 선택은 시간이 지남에 따라 한 데이터베이스 기술에서 다른 데이터베이스 기술로 변경될 수도 있고, 애플리케이션이 시작된 모든 것(예: 관계형 데이터베이스 외에 Rediscache 또는 Azure Cosmos DB 사용) 외에 추가적인 지속성 형식이 필요할 수도 있습니다.

 

이 원칙을 위반하는 몇 가지 예는 다음과 같습니다.

  • Base클래스가 필수인 경우
  • Interface구현이 필수인 경우
  • 자신을 저장하는 역할을 가지는 클래스(예: Active Record pattern)
  • 파라메터가 없는 생성자가 필수인 경우
  • 프로퍼티에 virtual 키워드가 필수인 경우
  • 지속성관련 attributes가 필수인 경우

클래스가 위의 특징이나 행동을 가지고 있다면, 지속할 유형과 지속성 기술 선택 간의 결합을 추가해야 하기 때문에 향후 새로운 데이터 액세스 전략을 채택하기가 더욱 어렵게됩니다.

참고

The Unit Of Work Pattern And Persistence Ignorance | Microsoft Docs

반응형
댓글