5
스마트 개체 나는 속성이 변경된 경우 원래 속성 값을 알고있는 모든 도메인 개체를 고려합니다. 스마트 개체는 일반적으로 기본 클래스를 가지며 GetPropertyValue/SetPropertyValue 메서드를 사용하여 속성을 구현합니다. 한편 POCO 객체는 일반적으로 기본 클래스가없고 간단한 속성을 구현합니다.도메인 개체 - "스마트 개체"vs POCO
public class SmartObject : BaseDomainObject
{
public int id
{
get { return (int)this.GetPropertyValue("Id"); }
set { this.SetPropertyValue("Id", value); }
}
}
public class POCO
{
public int id { get; set; }
}
나는 스마트 한 물건을 좋아하는데, 그것은 나를 위해 많은 노력을하기 때문이다. 난 쉽게 내 모든 파생 된 도메인 클래스에서 그들을 BaseDomainObject에 모든 유용한 기능을 추가 할 수 있습니다 :
- 일반 속성을 (ID, 상태 ... 등) 추적
- 객체 상태 (신규, 수정, 변경되지 않음)
- 모든 속성 (INotifyProperyChanged의 구현) 속성 변경에 대한 이벤트를 발생
- 파생 클래스 수있을 자동으로 내가 도움이 될 수있는 모든이 다른 행동을 할 수 있습니다
- (나는 거의이 유용 없지만) 직렬화 - 클론/Sync/IsPropertyDirty ...
한편 POCO는 매우 간단하며 기본 클래스에 종속되지 않습니다.
요즘 여기에 내가 있기 때문에 찬양 POCO의 많은 : 그것은 (일반적으로 JSON 등의 웹 브라우저에) 와이어를 통해 전송 될 수있다
- 는 다른에
순수 내 생각에 위의 이유는 오류라고 생각합니다.
- DTO는 전신환이며 도메인 객체가 아닙니다. 도메인 객체가 JSON으로 직렬화 될 때 손실되는 경우 데이터를 캡슐화하는 동작.
- 로직이없고 똑똑한 것도없는 더 많은 빈혈없는 도메인 모델에 대한 추적과 같은 순도 솔기에 대한이 추적.
이 모든 슬픈 표정으로 나는 여전히 그 POCO를 좋아하고 버그가있다. 당신의 의견 것입니다?
리치 도메인 모델을 사용하려는 경우 오염시키지 마십시오 기술 인프라 문제가 있습니다. 언급 한 모든 것들 - 상태 추적, 속성 변경 이벤트, 일련 번호 지정 - 이러한 것들 중 어느 것도 도메인과 관련이 없습니다. 그들은 비즈니스 도메인의 복잡성을 모델로 인코딩 할 수 없습니다. – MattDavey
한편 POCO는 도메인 복잡성을 모델로 인코딩하지 않습니다. DDD 표준에 따르면 두 가지 접근법 모두 매우 열악합니다. – MattDavey
@MattDavey 첫 번째 의견에 동의하지만 후자에 대해서는 잘 모르겠습니다. 포코! = 빈혈, 그게 당신이 암시하는 것이라면. 일반 올드 객체 지향 *에는 데이터 외에 동작 및 해당되는 경우 도메인 동작이 포함됩니다. – guillaume31