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 개발 사례에서 찾은 최고의 정보원입니다.
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에서 실수를 반복하지 마십시오.
DTO 클래스는 다른 소스의 데이터를 직렬화 / 직렬화하는 데 사용됩니다. 소스에서 객체를 직렬화 해제하려면 서비스, 파일, 데이터베이스 등 외부 소스가 중요하지 않습니다. 서비스의 일부만 사용하고 싶을 수도 있지만 데이터를 직렬화 해제하는 쉬운 방법을 원할 수도 있습니다. 목적. 그런 다음 사용하려는 XModel에 해당 데이터를 복사합니다. 시리얼 라이저는 DTO 객체를로드하는 아름다운 기술입니다. 왜? 객체를로드 (직렬화)하는 함수는 하나만 필요합니다.
TL; DR :
DTO는 상태 이전 패턴을 설명합니다. POCO는 아무것도 설명하지 않습니다. OOP에서 "객체"를 말하는 또 다른 방법입니다. 마틴 파울러 (Martin Fowler)가 공동으로 만든 POJO (Java)에서 유래 한 것입니다.
DTO는 해당 계층간에 상태를 전송하는 데 사용되는 객체 패턴입니다. 동작이 상태를 변경하지 않는 한 동작 (기술적으로는 포코 일 수 있음)을 가질 수 있습니다. 예를 들어, 직렬화되는 메소드가있을 수 있습니다.
POCO는 평범한 대상이지만 '평범한'이라는 의미는 특별하지 않다는 것입니다. 암시적인 패턴이없는 CLR 객체라는 의미입니다. 일반적인 용어. 다른 프레임 워크에서는 작동하지 않습니다. [JsonProperty]예를 들어 POCO에 속성 또는 EF 장식 이 있으면 POCO가 아니라고 주장합니다.
다음은 비교할 다양한 종류의 객체 패턴에 대한 몇 가지 예입니다.
이것들은 모두 단지 객체이지만, 대부분은 일반적으로 패턴에 연결되어 있습니다. 그래서 당신은 그것들을 "객체"라고 부르거나 그것의 의도에 대해 더 구체적이고 그것을 무엇인가에 의해 그것을 부를 수 있습니다. 이것이 우리가 디자인 패턴을 갖는 이유이기도합니다. 몇 가지 작품에서 복잡한 개념을 설명합니다. DTO는 패턴입니다. 집계 루트는 패턴이고 뷰 모델은 패턴입니다 (예 : MVC & MVVM). POCO는 패턴이 아닙니다.
POCO는 패턴을 설명하지 않습니다. OOP에서 클래스 / 객체를 참조하는 다른 방법 일뿐입니다. 그것을 추상적 인 개념으로 생각하십시오. 그들은 무엇이든 언급 할 수 있습니다. IMO는 단방향 관계가 있지만 일단 객체가 한 가지 목적 만 깔끔하게 제공 할 수있는 지점에 도달하면 더 이상 POCO가 아닙니다. 예를 들어 클래스를 일부 프레임 워크에서 작동하도록 장식으로 마크 업하면 더 이상 POCO가 아닙니다. 따라서:
이 둘을 구별하는 요점은 패턴을 명확하고 일관되게 유지하여 문제를 해결하지 않고 긴밀한 커플 링을 유도하는 것입니다. 예를 들어, 상태를 변경하는 메소드가있는 비즈니스 오브젝트가 있지만 API 엔드 포인트를 통해 다시 보낼 수 있도록 SQL Server 및 JsonProperty에 저장하기 위해 EF 데코레이션으로 지옥으로 장식되었습니다. 이 객체는 변경이 허용되지 않으며 다양한 속성 (예 : UserId, UserPk, UserKey, UserGuid)으로 인해 흩어질 수 있습니다. 여기서 일부는 DB에 저장되지 않도록 표시되고 다른 일부는 직렬화되지 않은 것으로 표시됩니다. API 엔드 포인트의 JSON).
그래서 만약 당신이 무언가 DTO라고 말한다면, 아마도 그것이 상태를 움직이는 것 이외의 다른 용도로 사용되지 않았는지 아마 확신 할 것입니다. 뷰 모델이라고 말하면 데이터베이스에 저장되지 않았는지 확인합니다. 도메인 모델이라고 말하면 도메인 외부에 의존하지 않는지 확인합니다. 그러나 당신이 나에게 뭔가 POCO라고 말하면, 당신은 나에게 전혀 말하지 않을 것입니다.
그들을 DTO라고 부르지 마십시오. 그것들은 Models .... Period 라고 불립니다 . 모델에는 동작이 없습니다. 이 바보 같은 용어 DTO를 누가 만들 었는지 모르겠지만 .NET이어야합니다. MVC의 뷰 모델을 생각해보십시오. 같은 댐 **의 모델은 서버간에 또는 와이어 기간 동안 계층간에 상태를 전송하는 데 사용되며 모두 모델입니다. 데이터가있는 속성. 이들은 와이어를 통과시키는 모델입니다. 모델, 모델 모델. 그게 다야.
어리석은 용어 DTO가 우리의 어휘에서 사라지기를 바랍니다.