Entity Framework 기능에 대한 질문

Question

저는 ASP.Net 환경에서 다년간 LINQ to SQL을 사용해 왔습니다. UI 및 BLL 계층은 웹 서비스로 구분되어 있으므로 지연로드, 변경 추적 등은 옵션이 아닙니다. 우리가 코드에서 어떤 일이 벌어지고 있는지 정확히 알았 기 때문에 어떤면에서 좋았습니다. BLL의 변경 사항을 지속적으로 유지할 책임이있었습니다 (엔티티가 새롭거나 업데이트 된 것인지를 알아 냈습니다). 일부 게으른 버그로 인해 예기치 않은 놀라움이 없었습니다. 적재가 어딘가에있다.

이제 작업을 이동하고 새 데스크톱 시스템 (WPF)에서 작업했습니다. 경계가 없습니다. 예 : UI 계층이 직접 BLL을 호출합니다 (단, 끝 부분에주의 사항 참조). EF5를 사용하려고 합니다만, EF가 제공하는 기능, 옵션 등의 수에 다소 압도되었습니다. 몇 가지 질문에 대한 답변을 얻을 수 있기를 희망합니다 ...

1. 경계를 넘어서 게으른로드를 사용해야합니까? 고객과 모든 주문을 표시하고 싶다면 UI가 BLL의 고객 만 요청한 다음 지연로드를 사용하여 주문에 액세스하겠습니까? UI에서 이렇게하는 것은 나에게 맞는 것 같지 않습니다. 게으른 로딩이 BLL에서 사용할 것이라고 가정합니다.

2. DbContext.Configuration.LazyLoadingEnabled을 사용하여 지연로드를 해제 할 수 있다고 생각하지만 내 BLL에서 지연로드를 사용하려면 어떻게해야합니까?하지만 UI에서 엔티티를 반환 할 때 UI를 수행하지 않으려 고합니다. 게으른로드?

3. 변경 추적, 자체 추적 엔티티 및 POCO는 어떻게됩니까? 내가 언제 사용해야합니까? LINQ to SQL (웹 서비스와 ASP.Net에 걸쳐 "상태"가 없으므로 변경 추적이 부적합 함)과 함께 작업했을 때 절 문제가되지 않았습니다. 나는 내가 그것을 익숙하게하는 모든 것을 비활성화시키고 싶어하지만, 나는 EF의 "선하심"을 놓치지 않을까 걱정된다. 데이터 지속성을 제어 할 수 없다는 것이 걱정 스럽습니다.

4. 저는 EF를 사용하여 데이터를 검색하고 재생 했으므로 일부 속성 모음 (예 : customer.Orders)에 "프록시"엔티티가 있음을 일부 엔티티 계층 구조에서 확인했습니다. 이것들은 무엇이고 언제 유용합니까?

5. 다시 프록시가 DbContext.Configuration.ProxyCreationEnabled을 통해 해제 될 수 있음을 알았지 만 설명서에 그 이상이 있으며 LazyLoadingEnabled 설정과의 관계가 있음을 알 수 있습니까?

6. EF "코드 우선"이 인기를 얻고있는 것으로 보입니다. 그것은 무엇을 당신에게 주는가? 나는 많은 데이터베이스를 작성하지 않고 SSMS에서 데이터베이스를 디자인하는 데 익숙하다.

마지막으로주의해야 할 점은 - 응용 프로그램의 UI 계층을 직접 BLL의 메소드를 호출하고 있지만, 미래에 우리가 (예를 들어, 웹 서비스를 통해)을 분리 할 수있는 작은 기회가있다. 이것이 설계 고려 사항 및 위에서 제기 한 몇 가지 질문에 어떤 영향을 미칩니 까?

여러 가지 질문을한데 묶는 것에 대해 사과드립니다. 내가 그들 모두에게 해답을 얻을 수 있다면, 미래의 상황에서 다른 사람들에게 유용 할 것입니다.

Answer 1

1. 제 생각에 지연 성로드는 BLL이 아닌 UI 계층에서 사용하도록 설계되었습니다. 특히 데이터 바인딩 시나리오 (예 : 마스터 세부 정보보기)에서 유용합니다. UI에 고객 목록이 있고 고객을 클릭하면 게으른로드로로드 할 수있는 고객의 주문을 표시 할 수 있습니다.사용자가 클릭 할 고객을 미리 알지 못하기 때문에 게으른 로딩을 사용하지 않으려는 경우 모든 고객의 모든 주문을로드해야합니다 (또는 자신 만의 이벤트 기반 하위 로딩 메커니즘을 구현하십시오). 이로 인해 불필요한 오버 헤드가 발생합니다.

   다른 측면에서 BLL의 게으른로드가 흥미로운 이유를 알 수 없습니다. 일반적으로 특정 비즈니스 로직을 수행하기 위해로드해야하는 데이터를 알고 있습니다. 당신이 그것을 알고있을 때 열심히 또는 명시 적 로딩을 사용할 수 있습니다. 네비게이션 속성에 액세스하고 게으른 로딩에 의존하는 것보다 1 ~ 2 행 더 많은 코드를 작성할 수 있지만 열정적이고 명시 적으로로드하면 코드에서 수행하는 작업과 데이터베이스에 액세스 할 때 분명합니다.

   게으른 로딩에는 배치되지 않은 컨텍스트가 필요하므로 UI ​​(또는 UI의 일부)가 사용되는 동안 컨텍스트가 유지되는 방식으로 BLL을 디자인해야합니다.

2. UI 레이어에서 느린 로딩을 원하지 않으면 BLL에서 열심히하고 명시 적으로로드하십시오. 지연로드가 설정된 엔티티를로드 한 후에는 지연로드를 끌 수 없습니다.

3. 새 프로젝트에서는 자체 추적 엔터티가 사용되지 않거나 the EF team suggests to not use them anymore 이상 (두 번째 참조 : http://msdn.microsoft.com/en-us/data/jj613668)입니다. 그들은 또한 to not use EntityObject derived entities anymore를 제안합니다. 그래서, POCO는 분명히 갈 길입니다.

   변경 내용 추적 자체는 EF의 핵심 기능이며 "스냅 샷 기반"변경 추적과 변경 내용 추적 프록시와 같은 두 가지 형태로 POCO에 사용할 수 있습니다. 기본값은 스냅 샷 기반 변경 추적입니다. 변경 추적 프록시를 사용하여 특정 시나리오에서 성능을 향상시킬 수 있습니다. 특히 수천 개의 엔티티가 관련되어 있고 단일 컨텍스트에서 업데이트해야하는 경우에 특히 유용합니다. 변경 추적 프록시에 대한 자세한 내용은 다음을 참조하십시오. http://blog.oneunicorn.com/2011/12/05/should-you-use-entity-framework-change-tracking-proxies/

4. 지연로드 또는 동적 변경 추적을 사용하는 경우 EF는 지연 시간이 설정된 POCO 엔티티에서 프록시를 만듭니다. 그것들은 엔티티 클래스에서 파생 된 동적 객체이며 지연로드 및 동적 변경 추적 (스냅 샷 기반이 아닌)을 가능하게하는 데 필요합니다.

5. 설정 ProxyCreationEnabled에서 false으로 설정하면 동적 변경 추적 및 지연로드의 경우 프록시 생성이 비활성화됩니다. 프록시 생성이 해제되어 있으면 LazyLoadingEnabled의 설정은 더 이상 중요하지 않습니다. 자세한 내용을 보려면 다음을 참조하십시오. https://stackoverflow.com/a/7112470/270591

6. 데이터베이스의 첫 번째 접근 방식에 익숙해지면 사용하십시오. EDMX 기반 접근 방식 인 코드 우선 또는 모델 우선으로도 똑같이 잘 지원됩니다. 코드가 처음에는 갖지 않는 몇 가지 고급 기능조차도 가지고 있습니다. 다른 전략에 대한 자세한 내용은 여기에 있습니다 : https://stackoverflow.com/a/5446587/270591

... 응용 프로그램의 UI 계층을 직접 BLL의 메소드를 호출하고 있지만, 미래에 우리가 를 분리하고자 할 가능성이 있습니다 그들 (예 : 웹 서비스를 통해). 이것이 디자인 의 고려 사항 및 위에 제기 한 질문 중 일부에 어떤 영향을 미칩니 까?

웹 서비스 경계를 ​​통해 컨텍스트 인스턴스를 전달할 수 없으므로 UI ​​레이어에서 지연로드를 더 이상 사용할 수 없습니다. 게으른 로딩은 UI가 (연결이 끊어진) 원격 브라우저 인 웹 응용 프로그램 에서처럼 유용하지 않게됩니다. 또한 연결된 엔티티를 추적하는 변경 사항을 놓치지 않게됩니다. 연결이 끊어진 엔터티 및 개체 그래프에 대한 변경 집합을 작성하는 것은 연결된 엔터티의 변경 내용 추적을 활용하는 것보다 어렵습니다.따라서이 "작은 기회"는 전체 애플리케이션 설계에 큰 영향을 줄 수 있습니다.