Entity Framework 6.0의 ORM 엔터티 대 도메인 엔터티
저자가 ORM 엔티티와 도메인 엔티티를 혼동해서는 안된다고 요약 한 다음 두 개의 기사 인 First 및 Second 를 우연히 발견 했습니다.
Code First 접근 방식을 사용하여 EF 6.0으로 코딩 할 때 정확히이 문제에 직면합니다. POCO 클래스를 도메인 / 비즈니스 개체뿐만 아니라 EF의 엔터티로 사용합니다. 하지만 EF 프레임 워크가 그렇게하도록 강제하기 때문에 속성을 공용으로 정의하거나 탐색 속성을 가상으로 만 정의하는 상황에 자주 직면합니다.
두 기사의 결론으로 무엇을 취해야할지 모르겠습니까? 예를 들어 엔티티 프레임 워크에 대한 CustomerEF 클래스와 내 도메인에 대한 CustomerD를 실제로 만들어야합니까? 그런 다음 CustomerD를 사용하는 리포지토리를 생성하여이를 CustomerEF에 매핑하고 일부 쿼리를 수행하고 수신 된 CustomerEF를 CustomerD에 다시 매핑합니다. 나는 EF가 내 도메인 엔터티를 데이터에 매핑하는 것이라고 생각했습니다.
그러니 제게 조언을 해주세요. EF가 제공 할 수있는 중요한 것을 간과합니까? 아니면 EF로 완전히 해결할 수없는 문제입니까? 후자의 경우이 문제를 관리하는 좋은 방법은 무엇입니까?
이 게시물의 일반적인 아이디어에 동의합니다. ORM 클래스 모델은 가장 먼저 데이터 액세스 계층의 일부입니다 (소위 POCO로 구성되어 있더라도). 지속성과 비즈니스 논리 (또는 기타 문제)간에 이해 상충이 발생하는 경우 항상 지속성을 위해 결정을 내려야합니다.
그러나 소프트웨어 개발자로서 우리는 항상 순수주의와 실용주의 사이에서 균형을 이루어야합니다. 지속성 모델을 도메인 모델로 사용할지 여부는 다음과 같은 여러 요인에 따라 달라집니다.
개발 팀의 규모 / 일관성. 전체 팀이 ORM 요구 사항 때문에 속성을 공개 할 수 있지만 전체적으로 설정해서는 안된다는 것을 알고있는 경우 큰 문제가 아닐 수 있습니다. 모든 사람이 ID 속성이 비즈니스 로직에서 사용되지 않는다는 것을 알고 (그리고 순종한다면) ID를 갖는 것은 큰 문제가 아닐 수 있습니다. 흩어져 있거나 경험이 없거나 훈련되지 않은 팀은 더 엄격한 코드 분리가 필요할 수 있습니다.
비즈니스 로직 문제와 지속성 문제가 겹칩니다. 객체 지향 디자인은 클래스 모델이 SOLID 원칙을 고수 할 때 성공 합니다. 그러나 이러한 원칙이 지속성 문제와 반드시 상충되는 것은 아닙니다. 우려 사항은 다르지만 결국 결과 요구 사항은 매우 유사 할 수 있습니다. 예를 들어, 두 가지 문제 모두 유효한 개체 상태와 올바른 연결이 필요할 수 있습니다.
그러나 객체가 절대 저장되어서는 안되는 상태에 일시적으로 있어야하는 사용 사례가있을 수 있습니다. 이것은 전용 도메인 클래스로 작업해야하는 이유 일 수 있습니다. 또 다른 이유는 엔터티 모델이 책임의 최상의 세분화를 수행 할 수 없기 때문일 수 있습니다. 예를 들어, 비즈니스 프로세스 "블랙리스트 고객"은 너무 많은 엔터티 개체에 흩어져있는 데이터를 필요로 할 수 있으므로 데이터와 이에 대해 작동하는 메서드를 캡슐화 할 수있는 새 도메인 클래스를 설계해야합니다. 즉, 엔티티가이 작업을 수행하면 Tell Do n't Ask 원칙에 위배됩니다.
레이어링의 필요성. 예를 들어, 데이터 액세스 계층이 서로 다른 데이터베이스 공급 업체를 대상으로하는 경우 공급 업체별로 교환 가능한 부분으로 구성되어야 할 수 있습니다 (예 : Oracle과 Sql Server 간의 데이터 유형의 미묘한 차이를 설명하거나 공급 업체별 기능을 활용하기 위해). 영속성 모델을 도메인 모델로 사용하면 벤더별 구현이 비즈니스 로직으로 빠져 나갈 것입니다. 정말 나쁠 것입니다. 데이터 액세스 계층은 정확히 계층이어야합니다.
(매우 사소한) 데이터의 양입니다. 개체를 만드는 데는 시간과 리소스가 필요합니다. 비즈니스 사례에 "많은"개체가 관련되어있는 경우 엔터티 개체와 도메인 개체를 모두 빌드하는 데 너무 많은 비용이들 수 있습니다.
그리고 의심 할 여지없이 더.
그래서 저는 항상 실용 주의자가 되려고 노력했습니다. 엔티티 클래스가 괜찮은 일을한다면 그렇게하세요. 불일치가 너무 크면 비즈니스 논리의 적절한 부분에 대한 비즈니스 도메인을 만듭니다. 나는 그것이 좋은 패턴이라고해서 (어떤) 디자인 패턴을 슬쩍 따르지 않을 것입니다. 게시물에서 설명한 것과는 달리 엔터티 모델을 비즈니스 모델에 매핑하려면 많은 유지 관리가 필요합니다. 엔터티 클래스와 거의 동일한 수많은 비즈니스 클래스를 생성하는 것을 발견하면 수행중인 작업을 다시 생각할 때입니다.
'Programing' 카테고리의 다른 글
| 제네릭으로 인터페이스를 구현하는 Java 추상 클래스 (0) | 2020.11.22 |
|---|---|
| NaN ^ 0 == 1 인 이유 (0) | 2020.11.22 |
| Visual Studio 2013에서 .less 파일에서 CSS 파일을 생성 할 수 있나요? (0) | 2020.11.22 |
| malloc은 Linux (및 기타 플랫폼)에서 할당을위한 백업 페이지를 느리게 생성합니까? (0) | 2020.11.22 |
| std :: shared_ptr이없는 이유 (0) | 2020.11.22 |