Microsoft의 Entity Framework O/R 매퍼를 사용하고 비즈니스 개체로 엔터티 클래스 (DB 개체에 매핑 된 생성 된 클래스)를 사용하고 있습니다. 괜찮습니까? 죄수 또는 찬성을 진술하십시오. 비즈니스 레이어와 프레젠테이션 간의 WCF 통신의 경우 어떻게해야합니까? 이러한 개체를 데이터 멤버로 보내는 방법은 무엇입니까?Entity Framework 엔터티를 비즈니스 개체로 사용 하시겠습니까?
저는 EF를 이런 식으로 사용하고 있습니다. 좋은 특징 중 하나는 생성 된 엔티티가 부분 클래스이므로 재생성 문제로부터 상당히 보호 된 방식으로 확장 할 수 있다는 것입니다.
Business Logic과 관련하여 EF와 관련된 몇 가지 일반적인 사용 시나리오를 설명하는 this link on MSDN을 살펴보십시오.
엔터티 프레임 워크는 엔터티 개체를 비즈니스 개체로 사용하기 위해 설계되었지만 비즈니스 개체는 ODM 기술 및 EDM 모델과 관련되어 있음을 명심해야합니다. EF 1.0에서는 persistence-ignorance 시나리오에 대한 지원이 없었지만 4.0에서는 지원이 추가되었습니다. 기본 클래스를 사용하지 않으려는 경우 interfaces을 구현할 수 있습니다.
.NET 3.5 SP1부터 추가 코드없이 WCF 서비스 메서드에서 매개 변수 및 반환 형식으로 사용할 수 있어야합니다.
업데이트 : Entity Framework 4.0/.NET 4.0에서 persistence-ignorance에 대한 지원이 있습니다. –
내 경험에 비추어 볼 때 응용 프로그램의 비즈니스 계층에서 EF 개체를 사용했지만 WFF 서비스 계층을 통해 프레젠테이션 계층으로 전환 할 때 EF 개체에서 뷰 개체를 만들 것입니다.
이 경우에는보기 만 프레젠테이션 레이어로 전달됩니다. 우리는 데이터를 표현하는 방법을 제어하고 프리젠 테이션 레이어에서 들어오는 데이터에 대해 방어적인 검증을 적용하기 위해이 작업을 수행합니다.
WCF 트랜잭션에서 EF 개체를 가져 오는 경우 EF 개체가 연결된 개체 컨텍스트가 손실됩니다. CodePlex에는이 작업을 도와주는 몇 가지 노력이 있지만 노력을 아끼지 않았습니다.
원본 개체 컨텍스트를 잃어 버리면 개체를 다시 첨부 할 수 없습니까? 동시성 문제를 직접 처리해야합니다.
WCF의 DataContract 개체로 EF 개체를 사용하지 않는 것이 좋습니다. 개체 개체 구현을 웹 서비스 클라이언트에 강력히 묶어두면 나중에 변경하기가 어려워 질 것이므로 더 많은 클라이언트 가지고있는 것을 계획하십시오.
두 제한은 내가으로 실행했는지 알고 있어야합니다 :
상속 객체가 탐색 속성이 가질 수 없습니다 - 당신이 다음에 "사람"클래스와 "고객"과 "공급 업체"가있는 경우 즉, 해당 고객 및 공급 업체는 Navigation 속성을 가질 수 없습니다.
메서드 및 계산 된 필드 (부분 클래스의 모든 항목)는 ADO.Net 데이터 서비스를 통해 전송되지 않습니다. ADO.Net 데이터 서비스를 사용하는 경우 부분 클래스의 Entity Framework 개체는 확장되지 않습니다. ADO.Net Data Services를 통해 전송됩니다.
이들은 일반적으로하지 쇼 스토퍼 항목 (탐색 속성에 대해 우리가 지금, 엔티티 프레임 워크를 상속을 사용하지 않음),하지만 자신에게 관심이 뭔가 될 수 있습니다.나는 앞으로의 릴리스에서이 두 항목을 모두 사용할 수 있기를 희망하고 있습니다.
WPF Application Framework (WAF)의 BookLibrary 샘플 응용 프로그램은 MVVM (Model-View-ViewModel) 패턴을 Entity Framework와 함께 사용하는 방법을 보여줍니다.
이 글을 쓰고있는 시점에서 처음으로 11k의 질문이 있었지만, 나는 대답이 부족하고 모든면에서 존경심을 가지고 응답의 질이 매우 놀랍습니다.
최근에 Entity Framework Code-First의 최신 버전을 적용하면이 문제가 더욱 복잡해지기 때문에이 질문에 답하고 싶습니다.
"엔터티 프레임 워크 엔터티를 비즈니스 개체로 사용 하시겠습니까?" 설명의
몇 점은 내가 시작하기 전에 :
이러한 개체는에 이르기까지 규칙이나 로직을 포함하기 위해 참조하는 것이 나에 대한 인상을 해요, "비즈니스 오브젝트"를 말할 때 예를 들어, 단순한 검증 (즉, 필수 필드)에서보다 복잡한 논리 (즉, 계산에 세금을 부과).
WCF에 관한 후속 질문에 답변 할 수 있다고 생각하지 않습니다. 그 이유는 간단히 말해서 객관적으로 EF에 대한 귀하의 질문에 비즈니스 목표로 대답 할 것이기 때문입니다. 그러면 객관적으로 제가 첫 번째 질문에 진정으로 객관적으로 대답하려는 내 시도의 모순을 입증하는 입장을 취하게 만듭니다.
"나는 클래스 (있는 생성 된 클래스를 Microsoft에서 엔티티 프레임 워크 O/R 매퍼 를 사용하여 엔티티를 사용하고 비즈니스 질문 객체로 EF에 말했다
... 은 DB 개체로 매핑 됨) 개체로 표시됩니다. 괜찮습니까? "
죄송합니다. 여기에 올바른 답변이 없습니다. 그것은 당신의 목적이 무엇인지, 그리고 가장 합리적인 설계로 결론을 내리고 그 이점과 단점을 완전히 이해하는 것에 달려 있습니다.
"당신의 단점이나 장점을 말씀 해주세요"
나는 당신이 물어 기뻐요! 나는 기꺼이 대답 할 것이고 희망은 여기서 장단점을 감안할 때, 당신이 당신의 비즈니스 객체에 대해 EF를 사용하는 것이 "OK"라고 믿는지에 대한 정보에 근거한 결정을 내릴 수 있다는 것입니다. 일반적으로, 나는 "소화"하기 쉽도록 찬성하고 단점을 없애기로했다. 그러나 나는 그것이 적절하다고 생각하지 않는다. 왜냐하면 나는 우리가 또한 매우 흥미로운 주제에 대한 불의를하고 있다고 생각하기 때문이다. 그리고 내 마음에 드네.
먼저 기술적으로 잠시 이야기 해 보겠습니다 ... EF 개체를 비즈니스 개체로 사용할 수 있으므로 기술적 인 방해를받을 수 없습니다. 사실, EF Code-First (CF)는 POCO를 만들고 간단한 검증을 위해 데이터 주석을 적용 할 수있게 해주고보다 복잡한 검증을 위해 IValidatableObject를 구현할 수있게함으로써 이것을 매우 쉽게 만듭니다.멋지다, 응?
여기에는 토론의 핵심이 있습니다.
EF 또는 모든 ORM은 데이터 관리를 지원하도록 설계되었습니다. 주요 책임은 데이터이므로 생성하는 객체는 데이터 중심입니다. 그래서, 당신이 또한 행동에 의해 당신의 물건을 디자인하려고 시도한다면, 당신은 약간의 수수께끼를 가지고 있습니다. 간단히 말해서이 수수께끼는 임피던스 불일치라고합니다. 이것을 묘사하십시오; 당신이 당신의 응용 프로그램에서 두 개의 필수 사용 사례가 : EF를 사용하는 경우 사용자 정보
의 읽기 전용 부분 집합을 표시하는 사용자
의 장단점이있다 할 당신이 볼 수 있었던 것처럼 그것은 "느낌" 귀하의 의견에 따라 긍정적이거나 부정적입니다.
정상적인 동작보다 코드 정상화를 믿는다면 크게 성공했다고 생각합니다. 해당 개체에 대한 데이터 및 비즈니스 유스 케이스를 처리하는 단일 개체를 작성하여 코드 양을 제한하고 잠재적으로 시간을 절약 할 수있었습니다.
당신이 비참하게 실패한 것보다 코드에 대한 행동의 정상화를 믿는다면 나는 생각한다. 코드를 저장하면 관리 작업을 어렵게 만들고 유지 관리 비용을 증가시킬 수있는 책임으로 객체 디자인이 희생되었습니다.
귀하의 의견에 관계없이 우리는이 비즈니스 객체가 여러 가지 책임을지고 데이터 객체의 동작 (데이터가 아님)이 최선이라는 것에 모두 동의 할 수 있습니다. 그것의 주된 책임은 데이터 관리와 그것의 부차적 인 책임은 단순한 & 복잡하고 사용자 편집과 읽기 전용 사용자 정보 표시와 관련된 비즈니스 규칙을 처리하는 것입니다. 객체 지향 디자인 (OOD)에서 객체의 디자인이 그 정체성과 행동으로 특징 지어 진다면,이 객체는 OOD의 정의를 고수하지 않기 때문에 혼란 스러울 수 있습니다.
기술적 인 관점에서 보면 사용자 개체를 요청할 때 상당한 양의 오버 헤드가 상속됩니다. 여기에는 읽기 전용 정보의 서브 세트 만 표시 할 때 모든 특성 및 비즈니스 룰 등이 포함될 수 있습니다.
그렇다면이 모든 것이 비즈니스 개체를 나타내는 데 EF를 사용해야하는지 여부와 관련이 있습니다.
음 ... 기술적으로 가능하지만 비즈니스 개체를 나타내는 데 EF 또는 ORM을 사용해야하는지 여부에 따라 다양한 철학 (좋거나 나쁨)이 있습니다. 위의 철학의 핵심을 목표로 시놉시스를 주었지만 Rocky Lhotka 및 Martin Fowler와 같은 개인이 훨씬 자세히 설명합니다.
당신이 취하는 방향은 응용 프로그램과 철학적 관점에 따라 결정될 가능성이 높습니다.이 방향은 당신이 이상 주의자 또는 실용 주의자 중 어느 정도인지에 따라 달라질 수 있습니다. 즉, 나는 이상 주의자 또는 실용 주의자라는 것이 사업 객체를 위해 EF를 사용하는 것과 상관 관계가 있다는 것을 암시하는 것이 아닙니다. 이는 단순히 이것에 영향을 미칠 것입니다.
이 글을 쓰는 시점에서 Microsoft는 비즈니스 논리를 처리하기 위해 EF가 만들어졌으며 그 방향으로 나아가는 것처럼 보였습니다. EF는 계속 진화하고 있으며 특정 기술적 한계가 사라져 결국 EF가 결국 두 세계의 최고를 만족시키는 데 사용될 수 있습니다. 다른 말로하면 결국 당신은 당신의 케이크를 먹을 수있을 것입니다.
희망이 도움이됩니다.
ORM의 지속성에 대한 무지가 우스꽝스럽지 않은 이유에 대한 질문에 답변하지 않는 이유는 데이터를 관리하는 것이 목적이라는 것을 고려하면 말입니다. :-) 미안, 나는 저항 할 수 없었다!
+1 : 나도이 작업을 수행하고 있으며, 아직 나를 붙잡은 사례를 찾지 못했습니다. 다이어그램, 목록 및 winform 응용 프로그램의 레이블에 내 엔티티 클래스 속성을 표시합니다. – Marcel
링크 주셔서 감사합니다. –