도메인 개체, POCO 및 엔터티의 차이점은 무엇입니까?


83

나는 그들이 모두 기본적으로 동일하다는 인상을 받았습니다. 모델 객체도 동일합니까?

지금 내 아키텍처에는 다음이 있습니다.

class Person 
{

    public string PersonId;        
    public string Name;
    public string Email;

    public static bool IsValidName() { /* logic here */ }
    public static bool IsValidEmail() { /* logic here */ }
}


class PersonService
{
    private PersonRepository pRepository;

    PersonService()
    {
        pRepository = new PersonRepository();
    }

    public bool IsExistingEmail(string email)
    {
        //calls repo method to see if email is in db
    }


    public Person GetPerson(email)
    {
        return pRepository.Get(email);
    }


    public void SavePerson(Person p)
    {
        if (Person.IsValidEmail(p.Email) && !IsExistingEmail(p.Email)
        {
            pRepository.Save(p);
        }
    }

}


class PersonRepository
{
    public void Save(Person p)
    {
        //save to db
    }

    public Person Get(string email)
    {
        //get from db
    }

    public bool IsExistingEmail(string email)
    {
        //see if email in db
    }

}

위의 클래스 중 어느 그래서이다 POCO, Domain Object, Model object, entity?

답변:


117

내 (비표준) 평신도 정의

  • POCO-일반 이전 % Insert_Your_Language % 개체. 논리가없는 유형입니다. 메모리에 데이터 만 저장합니다. 일반적으로 자동 속성, 때로는 필드 및 생성자 만 표시됩니다.
  • Domain object도메인과 관련된 클래스의 인스턴스입니다. 나는 아마도 도메인 개체에서 위성 또는 유틸리티 개체를 제외 할 것입니다. 예를 들어 대부분의 경우 도메인 개체에는 로깅, 형식화, 직렬화, 암호화 등과 같은 항목이 포함되지 않습니다. .
  • Model object나는 Domain object. 사람들은 이것을 서로 바꿔서 사용하는 경향이 있습니다 (나는 틀릴 수 있습니다)
  • Entity 가지고있는 수업 id
  • Repository한쪽 (예 : 데이터베이스, 데이터 서비스 또는 ORM)의 데이터 저장소와 서비스, UI, 비즈니스 계층 또는 기타 요청 기관에 대해 말하는 클래스입니다. 일반적으로 모든 데이터 관련 항목 (복제, 연결 풀링, 키 제약 조건, 트랜잭션 등)을 숨기고 데이터 작업을 간단하게 만듭니다.
  • Service일반적으로 공개 API를 통해 일부 기능을 제공하는 소프트웨어. 계층에 따라 예를 들어 RESTful 자체 포함 컨테이너 또는 필요한 유형의 특정 인스턴스를 찾을 수있는 클래스가 될 수 있습니다.

원래 답변

이들은 용어 크게 (분산) 도메인 기반 디자인에 사용됩니다. 그들은 동일하지 않습니다. 모델 개체 라는 용어 는 도메인 개체 의 동의어로 사용할 수 있습니다 .

도메인 개체. 도메인 전문가에게 의미있는 것을 나타내는 비즈니스 특정 영역의 개체입니다. 도메인 개체는 대부분 엔터티 및 값 개체로 표시됩니다. 일반적으로 도메인 레이어에있는 대부분의 개체는 모델에 기여하며 도메인 개체입니다.

실재. 속성이 아니라 연속성과 정체성의 스레드로 근본적으로 정의 된 객체입니다. (이것은 의미 한다이드 )

POCO. 복잡한 로직이없는 단순한 객체. 일반적으로 몇 가지 속성 만 있으며 ORM과 함께 사용되거나 데이터 전송 객체로 사용됩니다.

class Person-엔티티 및 POCO,이 클래스의 인스턴스는 Domain Object
class PersonService-Service
class PersonRepository-Repository


4
위의 코드 샘플을보고 약관을 어떻게 적용할지 알려주세요.
jpshook

좋은 대답입니다. 나는이 질문에 대답 할 준비가되었지만 그것은 당신의 대답의 사본이 될 것입니다. 엔티티 및 값 개체 외에 도메인 이벤트 등도 있습니다. 모든 개체는 도메인 레이어에 있으며 모델에 기여하는 것은 도메인 개체입니다.
Magnus Backeus 2011 년

1
POCO를 식별 할 필요가없는 경우 어떻게 ORM에서이를로드 할 수 있습니까? 논리적이지 않습니다!
Pascal

1
이 노골적으로 허위 정보가 가장 많이 찬성되고 받아 들여지는 이유는 무엇입니까? POJO는 논리가없는 유형 이 아닙니다 . 실제로 Martin Fowler는 Entity Bean과 대조하기 위해 POJO라는 용어를 특별히 만들었습니다 ( "우리는 Entity Bean을 사용하는 대신 일반 Java 객체로 비즈니스 로직을 인코딩하는 많은 이점을 지적했습니다."). martinfowler.com/bliki/POJO.html
이 사용자는 도움이 필요합니다.

1
내 의견이 강하게 표현 된 경우 미안하지만 , 용어 의 창시자 가 POJO를 명시 적으로 비즈니스 논리를 포함하도록 정의한 경우 귀하의 개인적인 경험은 실제로 중요하지 않습니다 . 사실, 그는 그가 안티 패턴이라고 생각하는 빈혈 도메인 모델 ( martinfowler.com/bliki/AnemicDomainModel.html ) 아래에서 귀하의 관행을 분류 할 것이며 대신 POJO를 사용할 것을 권장합니다. 안티 패턴인지 여부는이 정의의 범위를 벗어나지 만 한 가지 분명합니다. POJO는 비즈니스 로직이없는 객체를 의미 하지 않습니다 .
이 사용자는 도움이 필요합니다.

19

기본적으로 내부 논리로 귀결됩니다.

  1. 도메인 개체에는 유효성 검사 등과 같은 작업에 대한 내부 도메인 논리가 있습니다.
  2. 모델은 기본적으로 라이트 도메인 객체이며, 보유한 데이터에 대해서는 알고 있지만 어떻게 사용 될지에 대해서는 알지 못합니다.
  3. 엔터티는 데이터를 보유하고 데이터의 출처, 저장, 업데이트 등의 위치에 대한 내부 지식을 가지고 있습니다.
  4. POCO는 데이터를 보유하고 있으며 자산 컬렉션에있는 모든 항목의 총 가치와 같은 자체에 대한 내부 지식을 가질 수 있습니다.
  5. DTO는 가장 단순한 항목이며 데이터 만 보유하고 논리가 없습니다.

그것들은 모두 기본적으로 똑같은 용도로 사용됩니다.

코드 샘플에 따르면 Person 클래스는 도메인 개체 또는 모델이고 다른 2 개는 서비스 및 저장소입니다. 도메인 객체, Pocos, 모델, dtos 등은 메시지처럼 사용되며 한 계층에서 다음 계층으로 전달되며 PersonService와 같은 서비스 클래스는 애플리케이션의 계층이며 PersonRepository와 같은 Repository 클래스와 동일합니다. 좋은 오버 뷰를 보려면 http://bob-the-janitor.blogspot.com/2009/07/n-tier-design-revisit-part-1-over-view.html 을 참조하십시오.이 경우 사용에 대해 이야기하고 있습니다. 기본적으로 dto 인 데이터 엔티티


18

그것은 기능의 의미에 가깝습니다. 도메인 객체는 논리 구현에 특정한 것이며 단순한 POCO보다 더 복잡 할 수 있습니다. 엔터티는 (보통 지속성 매체와 관련하여) 무언가를 나타내는 의미를 가지고 있으며 POCO는 클래스의 빠른 식별자입니다. 모델은 객체를 나타내는 데 사용되는 용어 일뿐입니다 (일반적으로 상태를 포함하고 일반적으로 UI 또는 DB를 처리 함).

기능적 차이가있는 것이 아니라 무언가를 더 자세히 설명하기위한 다른 용어 일뿐입니다. 경주 용 자동차, 트럭, 가족 용 세단의 차이처럼. 모두 자동차이지만 각 용어가 더 설명 적입니다.


코드 샘플을 포함하도록 업데이트했습니다. 의견을 보내 주시겠습니까? 질문 할 때 올바른 용어를 사용하고 있는지 확인하고 싶습니다.
jpshook

11

위의 답변에는 이미 Domain 및 Model에 대한 좋은 설명이 있습니다.

데이터베이스 컨텍스트에서 엔티티는 엔티티 관계 모델 ERD의 항목을 의미 합니다. (즉, 테이블의 행)

에서 마이크로 소프트 소프 트 - EntityFramework - 세계 법인에서로드 및 데이터 (자료) 컨텍스트를 사용하여 데이터베이스에 저장 될 수있는 개체를 의미한다. 일반적으로 엔티티는 Data (Base) Context 없이는 존재할 수 없습니다. (Unit-) 이러한 클래스의 비즈니스 기능을 테스트하는 것은 어렵습니다.

Pocos (Plain Old CommonRuntime Objects) 는 PersistenceFramework (EntityFramework 또는 NHibernate)없이 존재할 수 있으므로 테스트하기가 훨씬 쉽습니다.

poco라는 단어 는 같은 이유로 자바 세계에서 만들어진 pojo (평범한 오래된 자바 객체) 의 적응입니다 .


반대 투표의 이유는 무엇입니까? 질문은 "도메인 개체, POCO 및 엔터티 간의 차이점은 무엇입니까?"였습니다. 나는 Entity와 Poco의 차이점을 설명했습니다
k3b

"위 답변에는 이미 도메인과 모델에 대한 좋은 설명이 있습니다." 다른 답변에 의존하는 답변을 유효한 답변으로 선택하려면 어떻게해야합니까?
jpshook

np. 돌이켜 보면 완전한 답변을 제공하도록 요청한 것입니다. 다음에 2 배 생각할 것입니다.
jpshook

3

도메인 개체는 응용 프로그램의 도메인 계층에있는 엔터티입니다. 주소 클래스. "모델"은 동일한 것을 의미합니다- "도메인 모델"의 엔티티.

POCO (일반 이전 CLR 개체)는 동작 (메서드)이 정의되지 않고 데이터 (속성) 만 포함하는 개체입니다. POCO는 일반적으로 레이어간에 데이터를 전달하기 위해 DTO (데이터 전송 개체)로 사용되며 데이터는 일반적으로 도메인 개체 / 엔티티를 채우는 데 사용됩니다.


POCO는 법인이 될 수 없습니까? POCO는 행동을 할 수 있지만 끈기가 무지해야한다고 생각했습니다.
jpshook

@Developr 예, 귀하의 도메인 모델 / 엔터티는 실제로 POCO 일 수 있습니다. 이것은 "빈혈"도메인 모델로 알려진 것입니다 -martinfowler.com/bliki/AnemicDomainModel.html
MattDavey

이 빈혈을 어떻게 생각하십니까? "리치 도메인 개체"를 어떻게 정의합니까? 도메인 개체가 데이터베이스와 직접 또는 간접적으로 상호 작용할 수없는 경우 어떤 종류의 풍부한 기능을 가질 수 있습니까?
jpshook

@Developr 전통적으로 POCO 클래스에는 풍부한 기능이없고 데이터 만 있기 때문에 POCO 개체로 구성된 도메인 모델이 빈약하다고 생각합니다. Seperation of Concerns 원칙 ( en.wikipedia.org/wiki/Separation_of_concerns )에 따라 도메인 모델의 객체는 데이터베이스 액세스와 전혀 관련이 없어야합니다 (따라서 널리 사용되는 "지속성 무시"라는 용어). 도메인 모델의 엔티티가 가져야하는 기능의 종류는 비즈니스 로직이 될 것입니다. 그들은 그들이 나타내는 문제 / 도메인의 논리적 규칙 및 워크 플로를 캡처하고 캡슐화해야합니다.
MattDavey
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.