Entity Framework-수명주기

일생

컨텍스트의 수명은 인스턴스가 생성 될 때 시작되고 인스턴스가 삭제되거나 가비지 수집 될 때 끝납니다.

컨텍스트 수명은 ORM을 사용할 때 내리는 매우 중요한 결정입니다.
컨텍스트는 엔터티 캐시처럼 수행되므로로드 된 모든 엔터티에 대한 참조를 보유하고 있으며 이는 메모리 소비가 매우 빠르게 증가 할 수 있으며 메모리 누수를 유발할 수도 있습니다.
아래 다이어그램에서 컨텍스트를 통해 응용 프로그램에서 데이터베이스로 또는 그 반대로 데이터 워크 플로의 상위 수준을 볼 수 있습니다.

엔티티 라이프 사이클

엔티티 라이프 사이클은 엔티티가 생성, 추가, 수정, 삭제되는 프로세스를 설명합니다. 엔티티는 수명 동안 많은 상태를가집니다. 엔티티 상태를 검색하는 방법을보기 전에 엔티티 상태가 무엇인지 살펴 보겠습니다. 상태는 유형의 열거 형입니다.System.Data.EntityState 다음 값을 선언합니다-

Added: 엔티티가 추가됨으로 표시됩니다.
Deleted: 엔티티가 삭제 된 것으로 표시됩니다.
Modified: 엔티티가 수정되었습니다.
Unchanged: 엔티티가 수정되지 않았습니다.
Detached: 엔티티는 추적되지 않습니다.

엔터티 수명주기의 상태 변경

때때로 엔티티의 상태는 컨텍스트에 의해 자동으로 설정되지만 개발자가 수동으로 수정할 수도 있습니다. 한 상태에서 다른 상태로의 모든 스위치 조합이 가능하지만 일부는 의미가 없습니다. 예를 들면Added 엔티티에 Deleted 상태 또는 그 반대입니다.

다양한 상태에 대해 논의 해 봅시다.

변경되지 않은 상태

엔터티가 Unchanged이면 컨텍스트에 바인딩되지만 수정되지 않았습니다.
기본적으로 데이터베이스에서 검색된 엔티티는이 상태입니다.
엔티티가 컨텍스트에 연결되면 (Attach 메서드 사용) 마찬가지로 Unchanged 상태가됩니다.
컨텍스트는 참조하지 않는 개체의 변경 사항을 추적 할 수 없으므로 연결될 때 변경되지 않은 것으로 간주합니다.

분리 된 상태

컨텍스트가 코드에서 개체 생성을 추적 할 수 없기 때문에 분리는 새로 생성 된 엔터티의 기본 상태입니다.
컨텍스트의 using 블록 내에서 엔티티를 인스턴스화하는 경우에도 마찬가지입니다.
Detached는 추적이 비활성화 된 경우 데이터베이스에서 검색된 엔터티의 상태이기도합니다.
엔터티가 분리되면 컨텍스트에 바인딩되지 않으므로 해당 상태가 추적되지 않습니다.
폐기, 수정, 다른 클래스와 함께 사용하거나 필요한 다른 방식으로 사용할 수 있습니다.
컨텍스트 추적이 없기 때문에 Entity Framework에는 의미가 없습니다.

추가 된 상태

엔티티가 추가됨 상태이면 옵션이 거의 없습니다. 실제로 컨텍스트에서 분리 할 수만 있습니다.
당연히 일부 속성을 수정하더라도 Modified, Unchanged 또는 Deleted로 이동하는 것은 의미가 없기 때문에 상태는 Added로 유지됩니다.
새 엔티티이며 데이터베이스의 행과 일치하지 않습니다.
이는 이러한 상태 중 하나에있는 기본 전제 조건입니다 (그러나이 규칙은 컨텍스트에 의해 적용되지 않음).

수정 된 상태

항목이 수정되면 변경되지 않음 상태 였고 일부 속성이 변경되었음을 의미합니다.
항목이 수정 됨 상태가되면 분리됨 또는 삭제됨 상태로 이동할 수 있지만 원래 값을 수동으로 복원하더라도 변경되지 않음 상태로 롤백 할 수 없습니다.
이 ID를 가진 행이 이미 데이터베이스에 존재하고이를 지속 할 때 런타임 예외가 발생하므로 엔티티를 분리하고 컨텍스트에 추가하지 않는 한 추가됨으로 변경할 수도 없습니다.

삭제 된 상태

엔터티는 Unchanged 또는 Modified이고 DeleteObject 메서드가 사용 되었기 때문에 Deleted 상태가됩니다.
이 상태에서 Detached 이외의 다른 값으로 무의미하게 변경되므로 가장 제한적인 상태입니다.

그만큼 using컨텍스트가 제어하는 모든 리소스를 블록의 끝에서 삭제하려는 경우 문. 당신이 사용할 때using 그런 다음 컴파일러는 try / finally 블록을 자동으로 생성하고 finally 블록에서 dispose를 호출합니다.

using (var context = new UniContext()) {

   var student = new Student {
      LastName = "Khan", 
      FirstMidName = "Ali", 
      EnrollmentDate = DateTime.Parse("2005-09-01")
   };

   context.Students.Add(student);
   context.SaveChanges();
}

장기 실행 컨텍스트로 작업 할 때 다음을 고려하십시오.

더 많은 개체와 해당 참조를 메모리에로드하면 컨텍스트의 메모리 사용량이 빠르게 증가 할 수 있습니다. 이로 인해 성능 문제가 발생할 수 있습니다.
더 이상 필요하지 않은 컨텍스트를 폐기해야합니다.
예외로 인해 컨텍스트가 복구 불가능한 상태가되면 전체 애플리케이션이 종료 될 수 있습니다.
데이터를 쿼리하고 업데이트하는 시간 사이의 간격이 커지면 동시성 관련 문제가 발생할 가능성이 높아집니다.
웹 애플리케이션으로 작업 할 때 요청 당 컨텍스트 인스턴스를 사용하십시오.
WPF (Windows Presentation Foundation) 또는 Windows Forms로 작업하는 경우 양식당 컨텍스트 인스턴스를 사용합니다. 이를 통해 컨텍스트가 제공하는 변경 추적 기능을 사용할 수 있습니다.

경험의 규칙

Web Applications

이제 웹 애플리케이션의 경우 요청 당 컨텍스트가 사용되는 것이 일반적이고 모범 사례입니다.
웹 애플리케이션에서 우리는 매우 짧지 만 모든 서버 트랜잭션을 보유하는 요청을 처리하므로 컨텍스트가 유지되는 적절한 기간입니다.

Desktop Applications

Win Forms / WPF 등과 같은 데스크톱 응용 프로그램의 경우 컨텍스트는 양식 / 대화 상자 / 페이지별로 사용됩니다.
우리는 우리의 어플리케이션을위한 싱글 톤으로서 컨텍스트를 원하지 않기 때문에 우리는 한 폼에서 다른 폼으로 이동할 때 그것을 처리 할 것입니다.
이런 식으로 우리는 컨텍스트의 많은 능력을 얻고 장기 실행 컨텍스트의 영향을받지 않을 것입니다.