이렇게 해보자 :

• 컨텍스트에 BlogPost를 첨부하십시오. 객체를 객체의 상태에 연결하면 모든 관련 객체와 모든 관계가 변경되지 않음으로 설정됩니다.
• context.ObjectStateManager.ChangeObjectState를 사용하여 BlogPost를 Modified로 설정하십시오.
• 태그 수집을 통해 반복
• context.ObjectStateManager.ChangeRelationshipState를 사용하여 현재 Tag와 BlogPost 간의 관계에 대한 상태를 설정합니다.
• 변경 사항을 저장하다

편집하다:

내 의견 중 하나가 EF가 병합을 수행 할 것이라는 잘못된 희망을 준 것 같습니다. 나는이 문제를 많이 가지고 있었고 내 결론은 EF가 당신을 위해 이것을하지 않을 것이라고 말한다. MSDN 에서도 내 질문을 찾은 것 같습니다 . 실제로 인터넷에는 그러한 질문이 많이 있습니다. 문제는이 시나리오를 다루는 방법이 명확하게 명시되어 있지 않다는 것입니다. 따라서 문제를 살펴 보겠습니다.

문제 배경

EF는 지속성이 업데이트, 삽입 또는 삭제해야하는 레코드를 알 수 있도록 엔터티의 변경 내용을 추적해야합니다. 문제는 변경 사항을 추적하는 것이 ObjectContext의 책임이라는 것입니다. ObjectContext는 연결된 엔터티에 대한 변경 사항 만 추적 할 수 있습니다. ObjectContext 외부에서 생성 된 엔티티는 전혀 추적되지 않습니다.

문제 설명

위의 설명을 바탕으로 EF는 엔터티가 항상 컨텍스트에 연결되는 연결된 시나리오에 더 적합하다는 것을 명확하게 말할 수 있습니다. 웹 응용 프로그램에는 요청 처리 후 컨텍스트가 닫히고 엔터티 콘텐츠가 클라이언트에 HTTP 응답으로 전달되는 연결이 끊긴 시나리오가 필요합니다. 다음 HTTP 요청은 다시 생성되고 새 컨텍스트에 연결되고 유지되어야하는 엔티티의 수정 된 콘텐츠를 제공합니다. 재생성은 일반적으로 컨텍스트 범위 밖에서 발생합니다 (지속성이 무시되는 계층 형 아키텍처).

해결책

그렇다면 이러한 단절된 시나리오를 어떻게 처리할까요? POCO 클래스를 사용할 때 변경 내용 추적을 처리하는 세 가지 방법이 있습니다.

• 스냅 샷-동일한 컨텍스트 필요 = 연결이 끊긴 시나리오에는 쓸모 없음
• 동적 추적 프록시-동일한 컨텍스트 필요 = 연결이 끊긴 시나리오에는 쓸모 없음
• 수동 동기화.

단일 엔티티에 대한 수동 동기화는 쉬운 작업입니다. 엔티티를 첨부하고 삽입을 위해 AddObject, 삭제를 위해 DeleteObject를 호출하거나 업데이트를 위해 ObjectStateManager에서 상태를 Modified로 설정하기 만하면됩니다. 진짜 고통은 단일 개체가 아닌 개체 그래프를 처리해야 할 때 발생합니다. 이 고통은 독립적 인 연결 (외래 키 속성을 사용하지 않는 연결)과 다 대다 관계를 처리해야 할 때 더욱 심해집니다. 이 경우 개체 그래프의 각 엔티티뿐만 아니라 개체 그래프의 각 관계도 수동으로 동기화해야합니다.

수동 동기화는 MSDN 문서의 솔루션으로 제안됩니다. 개체 연결 및 분리 는 다음 과 같이 말합니다.

개체는 Unchanged 상태로 개체 컨텍스트에 연결됩니다. 개체가 분리 된 상태에서 수정 된 것을 알고있어 개체의 상태 또는 관계를 변경해야하는 경우 다음 방법 중 하나를 사용하십시오.

언급 된 메서드는 ObjectStateManager = 수동 변경 추적의 ChangeObjectState 및 ChangeRelationshipState입니다. 유사한 제안이 다른 MSDN 문서 기사에 있습니다. 관계 정의 및 관리에 따르면 다음 과 같습니다.

연결이 끊어진 개체로 작업하는 경우 동기화를 수동으로 관리해야합니다.

또한 EF의 이러한 동작을 정확하게 비판하는 EF v1과 관련된 블로그 게시물 이 있습니다.

해결 이유

EF에는 Refresh , Load , ApplyCurrentValues , ApplyOriginalValues , MergeOption 등과 같은 많은 “유용한”작업 및 설정 이 있습니다. 그러나 내 조사에 따르면 이러한 모든 기능은 단일 엔터티에 대해서만 작동하며 스칼라 기본 설정에만 영향을줍니다 (= 탐색 속성 및 관계 아님). 오히려 엔터티에 중첩 된 복잡한 형식으로이 메서드를 테스트하지 않습니다.

기타 제안 된 솔루션

실제 병합 기능 대신 EF 팀은 문제를 해결하지 못하는 STE ( Self Tracking Entities) 라는 기능을 제공합니다 . 우선 STE는 전체 처리에 동일한 인스턴스가 사용되는 경우에만 작동합니다. 웹 애플리케이션에서는보기 상태 또는 세션에 인스턴스를 저장하지 않는 한 그렇지 않습니다. 그 때문에 EF를 사용하는 것이 매우 불행하고 NHibernate의 기능을 확인할 것입니다. 첫 번째 관찰은 NHibernate가 아마도 그러한 기능을 가지고 있다고 말한다 .

결론

이 가정 은 MSDN 포럼의 다른 관련 질문 에 대한 단일 링크로 끝낼 것 입니다. Zeeshan Hirani의 대답을 확인하십시오. 그는 Entity Framework 4.0 Recipes의 저자입니다 . 객체 그래프의 자동 병합이 지원되지 않는다고 말하면 그를 믿습니다.

그러나 여전히 내가 완전히 틀렸고 일부 자동 병합 기능이 EF에 존재할 가능성이 있습니다.

편집 2 :

보시다시피 이것은 2007 년 제안 으로 MS Connect 에 이미 추가 되었습니다. MS는 다음 버전에서 수행 할 작업으로 폐쇄했지만 실제로 STE를 제외하고는이 격차를 개선하기 위해 수행 된 작업이 없습니다.

답변

    db.Entry(dataobj).State = EntityState.Modified;
    db.SaveChanges();
    dataobj = db.ServiceTypes.Include(x => x.Categories).Single(x => x.Id == dataobj.Id);
    var it = _categories != null ? db.Categories.Where(x => _categories.Contains(x.Id)).ToList() : null;
    dataobj.Categories = it;
    db.SaveChanges();

report.ReportRoles.ToList.ForEach(Function(f) db.ReportRoles.Remove(f))
Dim newRoles = If(String.IsNullOrEmpty(model.RolesString), New String() {}, model.RolesString.Split(","))
newRoles.ToList.ForEach(Function(f) db.ReportRoles.Add(New ReportRole With {.ReportId = report.Id, .AspNetRoleId = f}))