데이터 맵퍼, 테이블 데이터 게이트웨이 (게이트웨이), DAO (Data Access Object) 및 리포지토리 패턴의 차이점은 무엇입니까?

https://stackoverflow.com/questions/804751

03-07-2019
|

문제

디자인 패턴 기술을 닦으려고 노력하고 있으며 이러한 패턴의 차이점은 무엇입니까? 그들 모두는 그들이 같은 것 같다 - 특정 엔티티의 데이터베이스 로직을 캡슐화하므로 호출 코드는 기본 지속성 계층에 대한 지식이 없다. 내 간단한 연구에서 모두 표준 CRUD 방법을 구현하고 데이터베이스 별 세부 사항을 추상화합니다.

이름 지정 규칙 (예 : CustomerMapper vs. CustomerDao vs. CustomerGateway vs. CustomerRepository) 외에도 차이점은 무엇입니까? 차이가 있다면 언제 서로를 선택 하시겠습니까?

과거에는 다음과 유사한 코드를 작성할 것입니다 (단순화, 당연히 - 일반적으로 공개 속성을 사용하지 않을 것입니다).

public class Customer
{
    public long ID;
    public string FirstName;
    public string LastName;
    public string CompanyName;
}

public interface ICustomerGateway
{
    IList<Customer> GetAll();
    Customer GetCustomerByID(long id);
    bool AddNewCustomer(Customer customer);
    bool UpdateCustomer(Customer customer);
    bool DeleteCustomer(long id);
}

그리고 CustomerGateway 모든 방법에 대한 특정 데이터베이스 로직을 구현하는 클래스. 때로는 인터페이스를 사용하지 않고 CustomerGateway 정적의 모든 메소드를 만들었습니다 (테스트 가능성이 떨어집니다).

Customer cust = CustomerGateway.GetCustomerByID(42);

이것은 데이터 맵퍼 및 리포지토리 패턴과 동일한 원칙 인 것 같습니다. DAO 패턴 (게이트웨이와 같은 것들이라고 생각합니다)도 데이터베이스 별 게이트웨이를 장려하는 것 같습니다.

내가 뭔가를 놓치고 있습니까? 똑같은 정확한 일을하는 3-4 다른 방법을 갖는 것은 조금 이상해 보입니다.

해결책

귀하의 예제 용어; Datamapper, DAO, DataTableGateway 및 Repository는 모두 비슷한 목적을 가지고 있습니다 (하나를 사용할 때 고객 객체를 되 찾을 것으로 예상). 그러나 의도/의미 및 결과 구현이 다릅니다.

ㅏ 저장소 "보다 정교한 쿼리 기능을 제외하고는 컬렉션처럼 행동합니다." [에반스, 도메인 구동 디자인] 그리고로 간주 될 수 있습니다 "메모리 외관의 물체" (저장소 토론)

ㅏ Datamapper "객체와 데이터베이스 사이의 데이터를 서로 독립적으로 유지하면서 맵퍼 자체를 유지합니다." (파울러, 포아아, 맵퍼)

ㅏ Tabledatagateway ~이다 "게이트웨이 (외부 시스템 또는 리소스에 대한 액세스를 캡슐화하는 개체) 데이터베이스 테이블에 대한 한 인스턴스는 테이블의 모든 행을 처리합니다." (Fowler, Poeaa, Tabledatagateway)

ㅏ 다오 "데이터 액세스 메커니즘에서 데이터 리소스의 클라이언트 인터페이스를 구분합니다. 특정 데이터 리소스의 액세스 API를 일반 클라이언트 인터페이스에 적용합니다." 허용 "데이터에 대한 데이터 액세스 메커니즘은 데이터를 사용하는 코드와 독립적으로 변경 될 수 있습니다." (태양 청사진)

저장소는 매우 일반적인 것처럼 보이며 데이터베이스 상호 작용의 개념을 드러내지 않습니다. DAO는 다른 기본 데이터베이스 구현을 사용할 수있는 인터페이스를 제공합니다. TableDatagateway는 특히 단일 테이블 주변의 얇은 래퍼입니다. Datamapper는 모델 객체가 데이터베이스 표현 (시간이 지남에 따라)과 독립적으로 진화 할 수 있도록하는 중개자 역할을합니다.

다른 팁

소프트웨어 디자인 세계에는 잘 알려진 오래된 것들과 패턴에 대한 새로운 이름을 발명하는 경향이 있습니다. 그리고 우리가 새로운 패러다임 (아마도 이미 존재하는 것들과 약간 다름)을 가지고있을 때, 일반적으로 각 계층에 대한 새로운 이름 세트가 제공됩니다. 따라서 "비즈니스 로직"은 우리가 SOA를한다고 말하기 때문에 "서비스 계층"이되고 Dao는 우리가 DDD를한다고 말하기 때문에 저장소가됩니다 (그리고 각각은 실제로 새롭고 독특한 것이 아니라 다시 : 새로운 이름입니다. 같은 책에 이미 알려진 개념에 대해). 그래서 나는이 모든 현대 패러다임과 약어가 정확히 같은 것을 의미한다고 말하지는 않지만, 당신은 실제로 그것에 대해 너무 편집증이되어서는 안됩니다. 대부분 이것들은 다른 가족의 것과 동일한 패턴입니다.

데이터 맵퍼 대 테이블 데이터 게이트웨이긴 이야기를 짧게 만들려면 :

데이터 맵퍼는 도메인 모델 객체 (Entity)를 Param으로 수신하고이를 사용하여 CRUD 작업을 구현합니다.

테이블 데이터 게이트웨이는 메소드에 대한 모든 매개 변수 (프리미티브)를 수신하며 도메인 모델 객체 (엔티티)에 대해 아무것도 알지 못합니다.

결국 두 사람은 메모리 내 객체와 데이터베이스 사이의 중재자 역할을합니다.

당신은 좋은 지적이 있습니다. 가장 친숙한 것을 선택하십시오. 나는 명확히하는 데 도움이 될만한 몇 가지를 지적하고 싶습니다.

테이블 데이터 게이트웨이는 주로 단일 테이블 또는보기에 사용됩니다. 여기에는 모든 선택, 인서트, 업데이트 및 삭제가 포함되어 있습니다. 따라서 고객은 귀하의 경우 테이블 또는보기입니다. 따라서 테이블 데이터 게이트웨이 객체의 한 인스턴스는 테이블의 모든 행을 처리합니다. 일반적으로 이것은 데이터베이스 테이블 당 하나의 객체와 관련이 있습니다.

데이터 맵퍼는 모든 도메인 로직과 독립적이며 결합되지 않습니다 (커플 링이 있거나 커플 링이 없다고 생각하지만). 객체와 데이터베이스 사이에 데이터를 전송하면서 서로 독립적 인 모자 자체를 유지하는 것은 중간 계층 일뿐입니다.

따라서 일반적으로 맵퍼에는 삽입, 업데이트, 삭제 및 테이블 데이터 게이트웨이와 같은 메소드가 표시됩니다. GetCustomerByid, GetCustomerByName 등이 있습니다.

데이터 전송 객체는 위의 두 패턴과 다릅니다. 주로 분포 패턴이기 때문에 위의 두 패턴과 같은 데이터 소스 패턴이 아니기 때문입니다. 원격 인터페이스로 작업 할 때 주로 사용하고 각 통화가 비싸 질 수 있으므로 전화를 덜 채팅해야합니다. 따라서 일반적으로 추가 비즈니스 규칙이나 처리를 적용하기 위해 모든 데이터를 서버로 다시 전달할 수있는 와이어를 통과 할 수있는 DTO를 설계합니다.

나는 지금까지 사용할 기회를 얻지 못했지만 다른 사람들의 답변을보고 있기 때문에 저장소 패턴에 정통하지 않습니다.

아래는 단지 내 이해입니다.

TableGateway/RowDatagateway: 이러한 맥락에서 Gateway는 각 "도메인 오브젝트"각 "도메인 개체 게이트웨이"에 매핑 된 특정 구현을 참조하고 있습니다. 예를 들어, 우리가있는 경우 사람, 그러면 우리는 가질 것입니다 persongateway 도메인 객체 사람을 데이터베이스에 저장합니다. 사람, 직원, 고객 등이있는 경우 Persongateway, Employeegateway 및 CustomerGateway가 있습니다. 각 게이트웨이에는 해당 객체에 대한 특정 CRUD 기능이 있으며 다른 게이트웨이와 관련이 없습니다. 여기에는 재사용 가능한 코드/모듈이 없습니다. 게이트웨이는 RowDatagateway 또는 TableGateway로 더 나눌 수 있으며 "ID"또는 "Object"를 전달하는 경우에 따라 다릅니다. 게이트웨이는 일반적으로 활성 레코드와 비교됩니다. 도메인 모델을 데이터베이스 스키마에 연결합니다.

저장소/Datamapper/DAO: 그들은 같은 것입니다. 그들은 모두 데이터베이스 엔티티를 도메인 모델로 전송하는 지속성 계층을 나타냅니다. 게이트웨이와 달리 저장소/Datamapper/DAO는 구현을 숨 깁니다. 당신은 사람 뒤에 페르소 웨이가 있는지 모릅니다. 그것은 당신이 신경 쓰지 않을 수도 있고 그렇지 않을 수도 있습니다. 각 도메인 개체에 대해 CRUD 작업이 지원되어야한다는 것입니다. 데이터 소스 및 도메인 모델을 분리합니다.

라이센스 : CC-BY-SA ~와 함께 속성

제휴하지 않습니다 StackOverflow