나는 그들이 모두 기본적으로 동일하다는 인상을 받았습니다. 모델 객체도 동일합니까?
지금 내 아키텍처에는 다음이 있습니다.
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?
답변
내 (비표준) 평신도 정의
POCO-일반 이전 % Insert_Your_Language % 개체. 논리가없는 유형입니다. 메모리에 데이터 만 저장합니다. 일반적으로 자동 속성, 때로는 필드 및 생성자 만 표시됩니다.Domain object도메인과 관련된 클래스의 인스턴스입니다. 나는 아마도 도메인 개체에서 위성 또는 유틸리티 개체를 제외 할 것입니다. 예를 들어 대부분의 경우 도메인 개체에는 로깅, 형식화, 직렬화, 암호화 등과 같은 항목이 포함되지 않습니다. .Model object나는Domain object. 사람들은 이것을 서로 바꿔서 사용하는 경향이 있습니다 (나는 틀릴 수 있습니다)Entity가지고있는 수업idRepository한쪽 (예 : 데이터베이스, 데이터 서비스 또는 ORM)의 데이터 저장소와 서비스, UI, 비즈니스 계층 또는 기타 요청 기관에 대해 말하는 클래스입니다. 일반적으로 모든 데이터 관련 항목 (복제, 연결 풀링, 키 제약 조건, 트랜잭션 등)을 숨기고 데이터 작업을 간단하게 만듭니다.Service일반적으로 공개 API를 통해 일부 기능을 제공하는 소프트웨어. 계층에 따라 예를 들어 RESTful 자체 포함 컨테이너 또는 필요한 유형의 특정 인스턴스를 찾을 수있는 클래스가 될 수 있습니다.
원래 답변
이들은 용어 크게 (분산) 도메인 기반 디자인에 사용됩니다. 그들은 동일하지 않습니다. 모델 개체 라는 용어 는 도메인 개체 의 동의어로 사용할 수 있습니다 .
도메인 개체. 도메인 전문가에게 의미있는 것을 나타내는 비즈니스 특정 영역의 개체입니다. 도메인 개체는 대부분 엔터티 및 값 개체로 표시됩니다. 일반적으로 도메인 레이어에있는 대부분의 개체는 모델에 기여하며 도메인 개체입니다.
실재. 속성이 아니라 연속성과 정체성의 스레드로 근본적으로 정의 된 객체입니다. (이것은 의미 한다 이 이드 )
POCO. 복잡한 로직이없는 단순한 객체. 일반적으로 몇 가지 속성 만 있으며 ORM과 함께 사용되거나 데이터 전송 객체로 사용됩니다.
class Person-엔티티 및 POCO,이 클래스의 인스턴스는 Domain Object
class PersonService-Service
class PersonRepository-Repository
답변
기본적으로 내부 논리로 귀결됩니다.
- 도메인 개체에는 유효성 검사 등과 같은 작업에 대한 내부 도메인 논리가 있습니다.
- 모델은 기본적으로 라이트 도메인 객체이며, 보유한 데이터에 대해서는 알고 있지만 어떻게 사용 될지에 대해서는 알지 못합니다.
- 엔터티는 데이터를 보유하고 데이터의 출처, 저장, 업데이트 등의 위치에 대한 내부 지식을 가지고 있습니다.
- POCO는 데이터를 보유하고 있으며 자산 컬렉션에있는 모든 항목의 총 가치와 같은 자체에 대한 내부 지식을 가질 수 있습니다.
- 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 인 데이터 엔티티
답변
그것은 기능의 의미에 가깝습니다. 도메인 객체는 논리 구현에 특정한 것이며 단순한 POCO보다 더 복잡 할 수 있습니다. 엔터티는 (보통 지속성 매체와 관련하여) 무언가를 나타내는 의미를 가지고 있으며 POCO는 클래스의 빠른 식별자입니다. 모델은 객체를 나타내는 데 사용되는 용어 일뿐입니다 (일반적으로 상태를 포함하고 일반적으로 UI 또는 DB를 처리 함).
기능적 차이가있는 것이 아니라 무언가를 더 자세히 설명하기위한 다른 용어 일뿐입니다. 경주 용 자동차, 트럭, 가족 용 세단의 차이처럼. 모두 자동차이지만 각 용어가 더 설명 적입니다.
답변
위의 답변에는 이미 Domain 및 Model에 대한 좋은 설명이 있습니다.
데이터베이스 컨텍스트에서 엔티티는 엔티티 관계 모델 ERD의 항목을 의미 합니다. (즉, 테이블의 행)
에서 마이크로 소프트 소프 트 – EntityFramework – 세계 법인에서로드 및 데이터 (자료) 컨텍스트를 사용하여 데이터베이스에 저장 될 수있는 개체를 의미한다. 일반적으로 엔티티는 Data (Base) Context 없이는 존재할 수 없습니다. (Unit-) 이러한 클래스의 비즈니스 기능을 테스트하는 것은 어렵습니다.
Pocos (Plain Old CommonRuntime Objects) 는 PersistenceFramework (EntityFramework 또는 NHibernate)없이 존재할 수 있으므로 테스트하기가 훨씬 쉽습니다.
poco라는 단어 는 같은 이유로 자바 세계에서 만들어진 pojo (평범한 오래된 자바 객체) 의 적응입니다 .
답변
도메인 개체는 응용 프로그램의 도메인 계층에있는 엔터티입니다. 주소 클래스. “모델”은 동일한 것을 의미합니다- “도메인 모델”의 엔티티.
POCO (일반 이전 CLR 개체)는 동작 (메서드)이 정의되지 않고 데이터 (속성) 만 포함하는 개체입니다. POCO는 일반적으로 레이어간에 데이터를 전달하기 위해 DTO (데이터 전송 개체)로 사용되며 데이터는 일반적으로 도메인 개체 / 엔티티를 채우는 데 사용됩니다.
답변
