순수한 POCO 모델의 주요 이점은 무엇입니까? 모델은 깨끗하고 단순해야하지만 모델 클래스 내에서 자식 개체의 유지 관리를 유지하는 경향이 있습니다. 예를 들어 내가있는 경우 ClassA와 ClassB다음과 같이 정의 :
public class ClassA
{
public string MyProp { get; set; }
public IEnumerable<ClassB> Children { get; }
public void AddChild(ClassB newChild) { /*... */ }
public void RemoveChild(ClassB child) { /* ... */ }
}
public class ClassB
{
public string SomeProp { get; set; }
}
add 및 remove 메소드에 본질적으로 잘못된 것이 있습니까? 대신 목록을 공개하고 클라이언트 코드가 null이 아닌 간단한 데이터 유효성 검사를 통과하고 다른 클래스에 복제하지 않는 것을 추가해야합니까?
도움을 주셔서 감사합니다. 감사합니다.
답변
두 질문은 관련이 없습니다.
순수한 POCO 모델을 사용하면 어떤 이점이 있습니까?
순수한 POCO는 일부 엔터프라이즈 프레임 워크, 규칙, []에 의존하지 않거나 유사하게 종속 된 일부 개체에 밀접하게 연결되어 있지 않습니다. 다시 말해서, 세상은 POCO를 완전히 바꿀 수 있으며, 걱정하지 않고 계속 일을합니다. 프레임 워크를 업데이트하거나 새 시스템으로 이동하거나 재미있게보고 프레임 워크를 분리 할 수 없습니다. 계속 작동합니다. 유일한 의존성은 명시 적으로 요구하는 것입니다.
POCO는 POJO 아이디어에 지나지 않습니다. 사람들이 C #을 사용하는 경우 Java라는 이름을 가진 개념을 설명 할 때 사람들이 당신을보고 웃기 때문에 J가 C로 변경되었습니다. 아이디어는 언어에 의존하지 않습니다. 그들은 단순히 그것을 Plain Old Objects라고 불렀을 것입니다. 그러나 누가 POO 사용에 대해 자랑하고 싶습니까?
파울러가 기원을 설명하도록하겠습니다.
이 용어는 Rebecca Parsons, Josh MacKenzie와 2000 년 9 월에 컨퍼런스에서 연설을 준비하는 동안 만들어졌습니다. 우리는 왜 사람들이 시스템에서 일반 객체를 사용하는 것에 반대하는지 궁금해했으며 단순한 객체에는 멋진 이름이 없기 때문이라고 결론 내 렸습니다. 그래서 우리는 그들에게 하나를 주었다. 그리고 그것은 매우 멋지게 붙 잡혔다.
다른 질문에 관해서는 :
add 및 remove 메소드에 본질적으로 잘못된 것이 있습니까?
답변
추가 및 제거를 통해 Collection<T>기능을 구현하고 있습니다. 왜 변경 가능한 클래스 IEnumerable<T>대신 List<T>또는 다른 가변 클래스 를 사용하고 있는지 스스로에게 물어보십시오 . 컬렉션이 읽기 전용이어야하기 때문이 아닙니다.
내가 생각할 수있는 유일한 이유는 게시하려는 액세스 방법을 제어하려는 것입니다. 이 경우 자신의 컬렉션 클래스를 만들고 목록을 캡슐화하고 select 메서드 Add 및 Remove and implement을 구현하는 것이 IEnumerable<T>좋습니다. 그런 다음 IEnumerable<T>자녀 컬렉션 유형 대신에 사용 하십시오.
그러나 그것은 List<ClassB>아마도 당신을 잘 섬길 것입니다.
답변
무엇에 AddChild추가하고 RemoveChild제거합니까? 데이터베이스 (또는 모든 종류의 지속성 저장소)에서 가져온 것이라면 일종의 활성 레코드가 있습니다. 항상 나쁜 것은 아니지만 @CandiedOrange가 언급했듯이 프레임 워크, 규칙, 종속성 등에 대해 걱정할 필요가 있습니다.
동시에 ClassA에서 ClassB (또는 적어도 InterfaceB) 로의 종속성이 모두 같은 응용 프로그램에있는 경우 피해야 할 시점은 무엇입니까? 응용 프로그램이 모델링하는 실제 영역에서는 상황이 서로 다릅니다. 실제 세계의 객체는 어떻게 그 “속한다”그들에게 다른 개체의 컬렉션을 가지고있다. 코드에서 이러한 관계를 나타내는 것이 전적으로 적합합니다.
조금 복잡 해지는 유일한 이유는 ClassB가 ClassA와 어떻게 연관되고 연관이 없는지 정확하게 관리해야 할 필요가 있기 때문입니다. 따라서 구현해야 할 작은 동작이 있습니다. 당신은 클래스 내에서 그것을 구현할 수 있거나 (완전히 “법적인”; /programming//a/725365/44586 참조 ), 또는 그 행동을 포함하는 별도의 클래스를 가질 수 있습니다. 개별 상황에 가장 적합한 것을하십시오.
어쨌든 POJO / POCO는 무의미하고 방해받지 않기 위해 실제로 OOP입니다. OOP 원칙을 준수하면 안전합니다.