데이터 매퍼, 테이블 데이터 게이트웨이 (게이트웨이), 데이터 액세스 개체 (DAO) 및 리포지토리 패턴의 차이점은 무엇입니까?

디자인 패턴 기술을 익히려고 노력하고 있는데,이 패턴들 사이의 차이점이 무엇인지 궁금합니다. 그것들은 모두 같은 것으로 보입니다-특정 엔티티에 대한 데이터베이스 로직을 캡슐화하므로 호출 코드는 기본 지속성 계층에 대해 알지 못합니다. 간단한 연구에서 모든 방법은 일반적으로 표준 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 "개체와 서로 매퍼 자체의 독립적들을 유지하면서 데이터베이스 간의 데이터 이동을" ( 파울러 PoEAA, 매퍼 )

TableDataGateway이 있다 "데이터베이스 테이블에 대한 게이트웨이 (외부 시스템 또는 리소스에 대한 액세스를 캡슐화 오브젝트). 일 개 인스턴스 핸들 테이블의 모든 행 "( 파울러 PoEAA, TableDataGateway )

DAO는 "/ 데이터 액세스 메커니즘에서 데이터 자원의 클라이언트 인터페이스를 분리하는 일반적인 클라이언트 인터페이스에 특정 데이터 리소스의 액세스 API를 적응" 수 "의 데이터를 사용하는 코드 독립적으로 변경하는 데이터 액세스 메커니즘을" ( 일 청사진 )

리포지토리는 데이터베이스 상호 작용에 대한 개념을 노출시키지 않는 매우 일반적인 것으로 보입니다. DAO는 다양한 기본 데이터베이스 구현을 사용할 수있는 인터페이스를 제공합니다. TableDataGateway는 특히 단일 테이블 주위의 얇은 래퍼입니다. DataMapper는 중개자 역할을하여 Model 객체가 데이터베이스 표현과 독립적으로 (시간이 지남에 따라) 발전 할 수 있도록합니다.

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

테이블 데이터 게이트웨이 대 데이터 매퍼 으로는 긴 이야기를 짧게합니다

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

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

Data Mapper는 도메인 논리와 더 독립적이며 결합이 적습니다 (결합이 있거나 결합하지 않은 것으로 생각하지만). 개체와 데이터베이스간에 데이터를 전송하는 동시에 개체와 맵퍼 자체와 독립적으로 유지하는 것은 중간 계층입니다.

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

데이터 전송 오브젝트는 위 두 패턴과 달리 주로 두 패턴과 같이 데이터 소스 패턴이 아니라 분배 패턴이기 때문에 위 두 패턴과 다릅니다. 원격 인터페이스로 작업 할 때 주로 사용하고 각 통화가 비싸 질 수 있으므로 통화가 덜 번거로워 야합니다. 따라서 일반적으로 추가 비즈니스 규칙 또는 처리를 적용하기 위해 모든 데이터를 서버로 다시 전송할 수있는 유선으로 직렬화 할 수있는 DTO를 설계하십시오.

나는 지금까지 사용할 기회를 얻지 못했지만 다른 답변을 볼 것이므로 저장소 패턴에 정통하지 않습니다.

아래는 내 이해입니다.

TableGateWay / RowDataGateWay :이 문맥에서 게이트웨이는 각 "도메인 오브젝트 게이트웨이"에 각 "도메인 오브젝트"맵핑이있는 특정 구현을 참조합니다. 예를 들어 Person 이있는 경우 PersonGateway 가 도메인 오브젝트 Person to database를 저장하도록합니다. Person, Employee, Customer 등이있는 경우 PersonGateway, EmployeeGateway 및 CustomerGateway가 있습니다. 각 게이트웨이에는 해당 객체에 대한 특정 CRUD 기능이 있으며 다른 게이트웨이와는 아무런 관련이 없습니다. 재사용 가능한 코드 / 모듈은 없습니다. "id"또는 "object"를 전달하는지 여부에 따라 게이트웨이를 RowDataGateway 또는 TableGateway로 더 나눌 수 있습니다. 게이트웨이는 일반적으로 활성 레코드와 비교됩니다. 도메인 모델을 데이터베이스 스키마에 연결합니다.

리포지토리 / DataMapper / DAO : 같은 것입니다. 이들은 모두 데이터베이스 엔터티를 도메인 모델로 전송하는 지속성 계층을 나타냅니다. 게이트웨이와 달리 Repository / DataMapper / DAO는 구현을 숨 깁니다. Person 뒤에 PersonGateway가 있는지 알 수 없습니다. 신경 쓰지 않을 수도 있습니다. 각 도메인 개체에 대해 CRUD 작업이 지원되어야합니다. 데이터 소스와 도메인 모델을 분리합니다.