POCO = 일반 Old CLR (또는 그 이상 : Class) Object
DTO = 데이터 전송 객체
이 게시물 에는 차이점이 있지만 필자가 읽은 대부분의 블로그는 DTO가 정의 된 방식으로 POCO를 설명합니다. DTO는 응용 프로그램 계층간에 데이터를 이동하는 데 사용되는 간단한 데이터 컨테이너입니다.
POCO와 DTO는 같은 것입니까?
답변
POCO는 OOP의 규칙을 따릅니다. 상태 와 행동 이 있어야합니다 (그러나 반드시 그런 것은 아닙니다) . POCO 마틴 파울러 [화폐로 주조 POJO에서 온다 일화 여기 ]. 그는 프레임 워크가 많은 EJB 구현을 거부하는 것을보다 섹시하게 만드는 방법으로 POJO라는 용어를 사용했습니다. POCO는 .Net의 동일한 컨텍스트에서 사용해야합니다. 프레임 워크가 객체의 디자인을 지시하지 않도록하십시오.
DTO의 유일한 목적은 상태를 이전하는 것이며 행동이 없어야합니다. 이 패턴의 사용 예는 Martin Fowler의 DTO 설명을 참조하십시오 .
차이점은 다음과 같습니다. POCO는 프로그래밍에 대한 접근 방식 (좋은 구식 객체 지향 프로그래밍)을 설명합니다. 여기서 DTO는 객체를 사용하여 “데이터를 전송”하는 데 사용되는 패턴 입니다.
POCO를 DTO처럼 취급 할 수는 있지만 빈 도메인 모델 을 만들 경우 위험이 따릅니다 . 또한 DTO는 비즈니스 영역의 실제 구조를 나타내지 않고 데이터를 전송하도록 설계되어야하므로 구조가 일치하지 않습니다. 그 결과 DTO는 실제 도메인보다 평평한 경향이 있습니다.
합리적으로 복잡한 도메인에서는 별도의 도메인 POCO를 만들어 DTO로 변환하는 것이 좋습니다. DDD (도메인 기반 디자인)는 부패 방지 계층 ( 여기 다른 링크 이지만 책을 구입하는 것이 가장 좋습니다 )을 정의합니다 . 이는 분리를 명확하게하는 좋은 구조입니다.
답변
내 블로그 기사에서 내 입장을 이미 언급 한 이후에 기여하는 것은 아마도 중복 일 수 있지만, 그 기사의 마지막 단락이 요약됩니다.
결론적으로 POCO를 사랑하는 법을 배우고 DTO와 같은 것에 대해 잘못된 정보를 퍼 뜨리지 않도록하십시오. DTO는 응용 프로그램 계층간에 데이터를 이동하는 데 사용되는 간단한 데이터 컨테이너입니다. POCO는 본격적인 비즈니스 객체로, 지속성 무지 (하나 이상의 저장 방법이 없음)라는 하나의 요구 사항이 있습니다. 마지막으로, 지미 닐슨 (Jimmy Nilsson)의 책을 아직 체크 아웃하지 않았다면, 해당 지역의 대학 스택에서 픽업하십시오. C #에 예제가 있으며 잘 읽습니다.
BTW, Patrick 저는 POCO를 라이프 스타일 기사로 읽었으며 완전히 동의합니다. 환상적인 기사입니다. 실제로 내가 추천 한 Jimmy Nilsson 책의 섹션입니다. 온라인에서 사용할 수 있다는 것을 몰랐습니다. 그의 책은 실제로 POCO / DTO / Repository / 및 기타 DDD 개발 사례에서 찾은 최고의 정보원입니다.
답변
POCO는 단순히 외부 프레임 워크에 의존하지 않는 객체입니다. 평야입니다.
POCO의 행동 여부는 중요하지 않습니다.
DTO는 도메인 객체 (일반적으로 동작이 풍부한)와 마찬가지로 POCO 일 수 있습니다.
일반적으로 DTO는 일반적으로 시스템의 경계를 벗어나는 직렬화 목적으로 외부 프레임 워크 (예 : 특성)에 종속 될 가능성이 높습니다.
일반적인 양파 스타일 아키텍처 (종종 광범위하게 DDD 방식으로 사용됨)에서 도메인 레이어는 중앙에 배치되므로이 시점에서 객체의 레이어 외부에 종속성이 없어야합니다.
답변
답변
DTO가 POCO가 될 수 있다고 생각합니다. DTO는 객체 사용에 관한 것이지만 POCO는 객체의 스타일에 가깝습니다 (건축 개념과 분리됨).
POCO가 DTO와 다른 한 가지 예는 도메인 모델 / 비즈니스 로직 모델 내부에서 POCO에 대해 이야기 할 때입니다. 이는 문제 도메인의 멋진 OO 표현입니다. 전체 응용 프로그램에서 POCO를 사용할 수 있지만 지식 유출과 같은 바람직하지 않은 부작용이 발생할 수 있습니다. DTO는 예를 들어 UI와 통신하는 서비스 계층에서 사용되며 DTO는 데이터를 평평하게 표현하며 UI에 데이터를 제공하고 변경 사항을 서비스 계층으로 다시 전달하는 데만 사용됩니다. 서비스 계층은 DTO의 두 가지 방법을 POCO 도메인 개체에 매핑하는 역할을합니다.
업데이트 마틴 파울러는 말했다 이 방법을 취할 무거운 도로이며, 도메인 층과 사용자 인터페이스 사이에 상당한 불일치가있는 경우에만 수행되어야한다.
답변
DTO의 기본 사용 사례는 웹 서비스에서 데이터를 반환하는 것입니다. 이 경우 POCO와 DTO는 동일합니다. 웹 서비스에서 POCO를 반환하면 POCO의 모든 동작이 제거되므로 동작이 있는지 여부는 중요하지 않습니다.
답변
일반적인 규칙은 다음과 같습니다. DTO == 악성 및 과도하게 엔지니어링 된 소프트웨어의 지표. POCO == 좋습니다. ‘기업’패턴은 Java EE 세계에서 많은 사람들의 두뇌를 파괴했습니다. .NET에서 실수를 반복하지 마십시오.