Entity Framework 엔터티를 비즈니스 개체로 사용합니까?
Microsoft의 Entity Framework O/R 매퍼를 사용하고 있으며 엔터티 클래스(DB 개체에 매핑되는 생성 클래스)를 비즈니스 개체로 사용하고 있습니다. 이거 괜찮아? 단점이나 장점을 말씀해 주십시오. 비즈니스 계층과 프레젠테이션 간의 WCF 통신의 경우 어떻게 해야 합니까? 해당 개체를 데이터 멤버로 보내는 방법은 무엇입니까?
저는 이 방식으로 EF를 사용하고 있으며 생성된 엔터티가 부분 클래스이므로 재생성 문제로부터 상당히 보호되는 방식으로 확장될 수 있다는 좋은 기능이 있습니다.
또한 Business Logic과 관련하여 EF의 몇 가지 일반적인 사용 시나리오를 설명 하는 MSDN의 이 링크를 살펴보십시오 .
우선, 이 글을 쓰고 있는 시점에 11,000개의 질문 조회수를 가지고 있었는데, 나는 답변이 부족하고 상당히 직설적인 질문이 주어졌음에도 불구하고 답변의 품질에 약간 놀랐습니다.
자, 이제 조금 숨을 들이마셨으니 이 질문에 대해 말씀드리고자 합니다. Entity Framework Code-First의 최근 릴리스에서는 이 질문이 더 많이 적용된다고 생각하기 때문입니다.
"Entity Framework 엔터티를 비즈니스 개체로 사용합니까?"
시작하기 전에 몇 가지 설명:
"비즈니스 개체"라고 하면 이러한 개체에 간단한 유효성 검사(예: 필수 필드)에서 더 복잡한 논리(예: 체크아웃에 대한 세금 처리)에 이르는 규칙이나 논리가 포함되어 있다는 인상을 받았습니다.
WCF에 관한 귀하의 후속 질문에 답변할 수 없다고 생각합니다. 그 이유는 단순히 EF에 대한 비즈니스 개체에 대한 귀하의 질문에 객관적으로 대답할 것이기 때문입니다. 그러면 주관적으로 첫 번째 질문에 솔직하고 객관적으로 대답하려는 제 시도와 모순되는 입장을 취하도록 강요할 것입니다.
즉, 비즈니스 개체 질문으로 EF에 ...
"저는 Microsoft의 Entity Framework O/R 매퍼를 사용하고 있으며 엔터티 클래스(DB 개체에 매핑되는 생성 클래스)를 비즈니스 개체로 사용하고 있습니다. 괜찮습니까?"
죄송합니다. 여기에는 옳고 그른 답이 없습니다. 그것은 당신의 목적이 무엇인지 그리고 당신이 그렇게 하는 것의 장단점을 충분히 이해하면서 가장 합리적인 디자인이라고 결론짓는 것에 달려 있습니다.
"단점이나 장점을 말해주세요"
물어봐주셔서 기뻐요! 기꺼이 답변해 드리겠습니다. 장단점을 감안할 때 비즈니스 개체에 EF를 사용하는 것이 "OK"라고 믿는지 여부에 대해 정보에 입각한 결정을 내릴 수 있기를 바랍니다. 일반적으로 저는 장단점을 구분하여 쉽게 "소화"할 수 있지만 여기에서는 적절하지 않다고 생각합니다. 그리고 내 마음에 사랑하는.
먼저 기술적으로 잠시 이야기하겠습니다. EF 개체를 비즈니스 개체로 사용할 수 있습니다. 기술적으로 그렇게 하는 것을 방해하는 것은 없습니다. 사실 EF Code-First(CF)를 사용하면 POCO를 생성할 수 있고 간단한 유효성 검사를 위해 데이터 주석을 적용하고 보다 복잡한 유효성 검사를 위해 IValidatableObject를 구현하는 기능을 제공하여 이 작업을 매우 쉽게 수행할 수 있습니다. 꽤 멋지죠?
거기에 토론의 핵심이 있습니다.
EF 또는 모든 ORM은 데이터 관리를 지원하도록 설계되었습니다. 주요 책임은 데이터이므로 생성하는 개체는 데이터 중심입니다. 따라서 행동으로 객체를 디자인하려는 경우 약간의 수수께끼가 있습니다. 간단히 말해서 이 수수께끼를 임피던스 불일치라고 합니다. 이것을 그림; 애플리케이션에는 두 가지 필수 사용 사례가 있습니다.
- 사용자를 편집하는 화면
- 사용자 정보의 읽기 전용 하위 집합을 표시하는 컨트롤
EF(모든 플레이버) 또는 해당 문제에 대해 모든 ORM을 사용하는 경우 동일한 "사용자" 개체를 사용하여 사용자를 저장하고 읽기 전용 필드의 하위 집합을 가져오기 위해 사용자를 가져오는 기능을 처리하는 데 끌릴 수 있습니다. 아마도 다음 몇 가지 이유 중 하나로 그렇게 할 것입니다.
- 많은 개발자와 마찬가지로 우리는 교육 중에 이 씨앗을 뇌에 심었습니다. "코드 통합"은 가장 중요하거나 DRY – Don't Repeat Yourself로 더 잘 알려져 있습니다. 따라서 속성과 같은 코드의 중복을 볼 수 있습니다. 부정적인 맥락.
- EF 4.1과 같은 ORM에는 여러 POCO/객체를 동일한 데이터베이스 테이블에 매핑하는 것과 같은 기술적 제한(및 해킹 해결 방법)이 있으므로 신념에 관계없이 강제로 수행해야 합니다.
- 애플리케이션을 시작하고 실행하는 빠르고 쉬운 방법입니다.
- 그것은 옳은 일처럼 "느껴진다"
이렇게 하는 것에는 장점과 단점이 있으며, 이는 자신의 의견에 따라 긍정적인 방향인지 부정적인 방향으로 볼 수 있는지 알 수 있습니다.
나는 당신이 행동보다 코드의 정규화를 믿는다면 당신이 크게 성공했다고 생각합니다. 단일 개체를 작성하여 해당 엔터티에 대한 데이터 및 비즈니스 사용 사례를 처리함으로써 코드의 양을 제한할 수 있었고 잠재적으로 시간을 절약할 수 있었습니다.
그리고 나는 당신이 비참하게 실패한 것보다 코드에 대한 행동의 정규화를 믿는다면 가정합니다. 코드를 절약함으로써 잠재적으로 관리를 어렵게 만들고 유지 관리 비용을 증가시키는 책임으로 인해 개체를 설계하는 것을 희생했습니다.
당신의 의견과 상관없이 우리는 아마도 이 비즈니스 개체가 여러 책임을 맡았고 개체의 동작(데이터가 아님!)이 기껏해야 부차적이라는 데 모두 동의할 것입니다. 주요 책임은 데이터 관리이고 부차적인 책임은 사용자 편집 및 읽기 전용 사용자 정보 표시와 관련된 간단하고 복잡한 비즈니스 규칙을 처리하는 것입니다. 객체 지향 디자인(OOD)에서 객체의 디자인이 그 아이덴티티와 행동으로 특징지어진다면, 이 객체는 OOD의 정의를 따르지 않기 때문에 혼란스러운 개인일 수 있습니다.
기술적인 관점에서 고려해야 할 사항은 사용자 개체를 요청할 때마다 상당한 양의 오버헤드를 상속받습니다. 여기에는 읽기 전용 정보의 하위 집합만 표시할 때 모든 속성 및 비즈니스 규칙과 같은 항목이 포함될 수 있습니다.
그렇다면 이 모든 것이 내 비즈니스 개체를 나타내는 데 EF를 사용해야 하는지 여부와 어떤 관련이 있습니까?
글쎄요... 기술적으로 가능하지만 비즈니스 개체를 나타내기 위해 EF 또는 ORM을 사용해야 하는지 여부에 대한 다양한 철학(일부 좋은 것, 나쁜 것)이 있습니다. 위에서 이러한 철학의 핵심을 겨냥한 시놉시스를 제시했지만 Rocky Lhotka 및 Martin Fowler와 같은 개인이 훨씬 더 자세히 문서화했습니다.
당신이 취하는 방향은 응용 프로그램과 철학적 관점에서 볼 때 당신이 얼마나 이상주의자인지 실용주의자인지에 달려 있습니다. 즉, 이상주의자나 실용주의자가 비즈니스 개체에 EF를 사용하는지 여부와 상관 관계가 있다는 의미는 아닙니다.
이 글을 쓰는 시점에서 Microsoft는 EF가 비즈니스 논리를 처리하도록 구축되었으며 옳든 그르든 그 방향으로 더 많이 움직이는 것처럼 보입니다. EF는 끊임없이 진화하고 있으며 EF가 궁극적으로 두 세계의 장점을 모두 만족시키는 데 사용될 수 있도록 특정 기술적 한계가 해소되고 있습니다. 즉, 결국 당신은 당신의 케이크를 가지고 그것을 먹을 수 있습니다.
도움이 되었기를 바랍니다.
Off to answer a question on whether or not persistence ignorance with an ORM is ridiculous considering the purpose behind it is to manage data. :-) Sorry, I couldn’t resist!
The Entity framework was designed for the entity objects to be used as business objects, but you should keep in mind that the business objects will be tied to O/R technology as well as the EDM model. In EF 1.0, there wasn't any support for persistence-ignorance scenarios, but support was added in 4.0. You can implement interfaces, if you don't want to use any of their base classes.
As of .NET 3.5 SP1, they should also be usable as paramater and return types in WCF service methods without any additional code.
In my experience, we've used EF objects within the business layer of our application, but when we make the transition into the presentation layer through our WCF service layer, we will create view objects from the EF objects.
In our case, only the view is passed to the presentation layer. We do this to control how the data is presented and apply defensive validation for data coming in from the presentation layer.
In the case of ueing EF objects in the WCF transaction, you'll lose the object context that the EF object was associated. There are some efforts in CodePlex that try to help with this but I havn't kept up with their efforts.
Two limitations to be aware of that I have run into are:
Inherited Objects cannot have Navigation Properties - i.e. if you have a "person" class and then a "customer" and "supplier" those customer and suppliers cannont have Navigation properties.
Methods and Calculated Fields (anything in the partial classes) are not transmitted over ADO.Net Data Services - if you are also using ADO.Net Data Services anything you expand the Entity Framework objects on in partial classes will not be transmitted over ADO.Net Data Services.
These are generally not show-stopper items (for navigation properties we just don't use inheritance on entity framework, for now), but might be something of interest to yourself. I'm holding out hope that a future release will enable both of these items.
Can't you just re-attach the objects if they lose their original object context? You'd need to handle concurrency-issues yourself though.
I wouldn't recommend using EF objects as DataContract objects for WCF, as you'd tie very strongly your implementation of entity objects to web service clients, change will be hard to do in the future, harder the more clients you plan on having.
The BookLibrary sample application of the WPF Application Framework (WAF) shows how the Model-View-ViewModel (MVVM) pattern can be used in combination with the Entity Framework.
ReferenceURL : https://stackoverflow.com/questions/217655/using-entity-framework-entities-as-business-objects
'IT이야기' 카테고리의 다른 글
| ggmap 오류: GeomRasterAnn이 호환되지 않는 버전의 ggproto로 빌드되었습니다. (0) | 2021.10.15 |
|---|---|
| 보안을 처리하고 사용자가 입력한 URL로 XSS를 방지하는 가장 좋은 방법 (0) | 2021.10.14 |
| 내부의 모든 줄 바꿈 문자(\n)와 일치하는 정규식 (0) | 2021.10.14 |
| Eclipse에서 Java의 도달할 수 없는 코드 오류 대 데드 코드 경고? (0) | 2021.10.14 |
| SQL Server 2008에서 트랜잭션 로그를 보는 방법 (0) | 2021.10.14 |