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

데이터 매퍼, 테이블 데이터 게이트웨이 (게이트웨이), 데이터 액세스 개체 (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는 모두 비슷한 목적 (사용할 때 Customer 객체를 되 찾을 것으로 예상)이 있지만 의도 / 의미 및 결과 구현이 다릅니다.

저장소는 "더 정교한 쿼리 기능이 제외 모음 같은 역할" [ 에반스, 도메인 디자인을 기반 ]과 같이 고려 될 수있다 "메모리 외관 객체" ( 저장소 토론 )

DataMapper "개체와 서로 매퍼 자체의 독립적들을 유지하면서 데이터베이스 간의 데이터 이동을" ( 파울러 PoEAA, 매퍼 )

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

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

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

---

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

---

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

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

테이블 데이터 게이트웨이는 메소드의 모든 매개 변수 (기본 요소)를 수신하며 도메인 모델 오브젝트 (엔티티)에 대한 정보를 알지 못합니다.

결국 둘 다 메모리 내 개체와 데이터베이스 간의 중재자 역할을합니다.

---

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

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

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

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

Data transfer object differs from the above two patterns, mainly because it is a distribution pattern and not a data source pattern as above two patterns. Use it mainly when you are working with remote interface and need to make your calls less chatty as each call can get expensive. So usually design an DTO which can be serialized over wire that can carry all the data back to the server for applying further business rules or processing.

I am not well versed in repository pattern as I did not get a chance to use till now but will be looking at others answers.

---

Below is just my understanding.

TableGateWay/RowDataGateWay: In this context, Gateway is referring a specific implementation that has each "domain object" mapping to each "domain object gateway". For example, if we have Person, then we will have a PersonGateway to store the domain object Person to database. If we have Person, Employee, Customer, etc, we will have PersonGateway, EmployeeGateway, and CustomerGateway. Each gateway will have specific CRUD function for that object and it has nothing to do with other gateway. There is no reusable code/module here. The gateway can be further divided into RowDataGateway or TableGateway, depends if you pass an "id" or an "object". Gateway is usually compared with Active record. It ties your domain model to database schema.

Repository/DataMapper/DAO: They are the same thing. They all refer to the Persistence layer that transfer database entities to domain model. Unlike gateway, the Repository/DataMapper/DAO hide the implementation. You don't know if there is a PersonGateway behind Person. It may, or it may not, you don't care. All you know is it must have CRUD operations supported for each domain object. It decouple the data source and domain model.

참고URL : https://stackoverflow.com/questions/804751/what-is-the-difference-between-the-data-mapper-table-data-gateway-gateway-da