DTO. 속성 또는 필드?

WCF를 통해 비즈니스 개체를 전송하려면 일부 DTO 클래스를 만들어야합니다.DTO. 속성 또는 필드?

이들은 기능이없는 데이터 봉지 일 뿐이므로 필드를 사용할 수없는 이유가 있습니까? 아니면 속성으로 제대로 표시 할 수있는 적절한 이유가 있습니까?

//fields 
[DataContract] 
class CustomerDTO 
{ 
    [DataMember] public int  Id; 
    [DataMember] public string Name; 
} 

//or properties? 
[DataContract] 
class CustomerDTO 
{ 
    [DataMember] public int Id    { get; set; } 
    [DataMember] public string Name    { get; set; } 
}

출처

2012-05-31 GazTheDestroyer

이없이 기능을 가진 데이터의 단지 가방이기 때문에, 난 그냥 필드

여기에 공공 분야에 대한 더 강력한 인수가 없습니다

를 사용할 수없는 이유가있다. 그러나 캡슐화의 일반적인 인수가 유지되지 않도록 DTO 내부에 로직 (동작)이 없기 때문에 이것이 단지 실현된다는 것을 인식하십시오.

나는 여전히 속성을 선호하지만 여기서는별로 필요하지 않습니다.

출처

2012-05-31 10:02:49

고마워. 순전히 일관성을 위해 속성을 사용합니다. – GazTheDestroyer

저는 필드를 직접 노출하지 않으므로 대부분의 회사는 표준에서 이것을 금지합니다. 효과적으로 캡슐화를 완전히 버립니다. DTOs, 더 복잡한 무언가의 표현은 그들의 속성이 어쨌든 캡슐화를 거의 깨뜨리는 이상한 경우입니다. 개인적으로, 나는 그들이 그곳에있는 그대로의 속성을 사용할 것입니다. 또한 "더티 (dirty)"기능 등을 구현할 수 있습니다. 필드를 직접 조정할 필요가있는 경우에는 그렇게하기가 쉽지 않습니다.

출처

2012-05-31 10:00:10

속성에 대한 한 가지 문제는 속성에 구조체 형식이있는 경우 해당 구조체의 일부에 액세스 할 때 모든 내용의 임시 복사본을 추가로 만들어야한다는 것입니다. 이러한 낭비적인 복사 작업은 구조체 필드를 노출 할 때 필요하지 않습니다. – supercat

DataMember 속성은 공개 입력란과 속성 모두에서 작동하므로 둘 중 하나만 가능합니다. 그러나 속성을 고집하는 것이 좋습니다.

특히 StyleCop을 사용하는 경우 rule SA1401을 위반하게됩니다.

이 규칙의 존재 이유는 실제로 적용되지 않지만 지속적인 통합 서버에서 빌드의 일부로 StyleCop 유효성 검사를 실행하는 경우 유지 관리 문제가 될 수 있습니다.

출처

2012-05-31 10:09:06 devdigital

솔루션이 DTO를 특정 위치에 배치하는 경우 해당 위치에 대해서만이 특정 규칙에 대한 스타일 윗 덮어 쓰기를 적용 할 수 있습니다. – Oded

사실, 아직 해결해야 할 유지 관리 문제입니다. – devdigital

중 하나를 사용할 수 있습니다. 성능에 영향을 미치지 않으므로 공용 필드에서 작동하지 않는 일부 직렬화 프레임 워크 나 유사한 것을 실행할 경우에 대비하여 속성을 사용하지 않는 것이 안전합니다. WCF 프록시 생성이 공용 속성과 백업 민간 분야, 당신은 서비스 측면에서 공공 필드를를 사용하는 경우에도 와 클라이언트 측에서 그 DTO들을 만들 것

참고. 어떻게 든 원하지 않는다면 서비스와 클라이언트간에 DTO 라이브러리를 공유해야합니다.

출처

2012-05-31 10:34:10

DTO. 속성 또는 필드?

답변

관련 문제