개체 상태 및 변경 내용 추적(LINQ to SQL)
LINQ to SQL 개체는 항상 특정 상태에 참여합니다. 예를 들어, LINQ to SQL에서 새 개체를 만들 경우 개체는 Unchanged 상태입니다. 직접 만든 새 개체는 DataContext에 알려져 있지 않으며 Untracked 상태입니다. SubmitChanges를 실행하고 나면 LINQ to SQL에 알려진 모든 개체는 Unchanged 상태가 됩니다. 유일한 예외는 데이터베이스에서 삭제된 개체로 이러한 개체는 Deleted 상태이고 해당 DataContext 인스턴스에서 사용할 수 없습니다.
개체 상태
다음 표에서는 LINQ to SQL 개체의 가능한 상태를 보여 줍니다.
상태 |
설명 |
|---|---|
Untracked |
LINQ to SQL에 의해 추적되지 않는 개체입니다. 여기에는 다음과 같은 예가 포함됩니다.
|
Unchanged |
현재 DataContext를 사용하여 검색되었으며 만들어진 이후 수정된 것으로 알려지지 않은 개체입니다. |
PossiblyModified |
DataContext에 연결된 개체입니다. 자세한 내용은 N 계층 응용 프로그램의 데이터 검색 및 CUD 작업(LINQ to SQL)을 참조하십시오. |
ToBeInserted |
현재 DataContext를 사용하여 검색되지 않은 개체입니다. 이로 인해 SubmitChanges 동안 데이터베이스에 INSERT가 발생합니다. |
ToBeUpdated |
검색된 이후로 수정되었다는 것이 알려진 개체입니다. 이로 인해 SubmitChanges 동안 데이터베이스에 UPDATE가 발생합니다. |
ToBeDeleted |
삭제되도록 표시된 개체이며 이로 인해 SubmitChanges 동안 데이터베이스에 DELETE가 발생합니다. |
Deleted |
데이터베이스에서 삭제된 개체입니다. 이 상태는 최종 상태이며 더 이상의 전환은 허용되지 않습니다. |
개체 삽입
InsertOnSubmit을 사용하여 Inserts를 명시적으로 요청할 수 있습니다. 또는 LINQ to SQL에서는 업데이트해야 하는 알려진 개체 중 하나에 연결된 개체를 찾아 Inserts를 유추할 수 있습니다. 예를 들어 Untracked 개체를 EntitySet<TEntity>에 추가하거나 EntityRef<TEntity>을 Untracked 개체로 설정할 경우 그래프에서 추적된 개체를 통해 Untracked 개체에 연결할 수 있습니다. SubmitChanges를 처리하는 동안 LINQ to SQL은 추적된 개체를 순회하면서 추적되지 않는 도달 가능한 모든 영구 개체를 검색합니다. 이러한 개체는 데이터베이스에 삽입할 후보입니다.
상속 계층 구조에 있는 클래스의 경우 InsertOnSubmit(o)은 또한 개체 o의 형식과 일치하도록 판별자로 지정된 멤버의 값을 설정합니다. 기본 판별자 값과 일치하는 형식의 경우 이 작업이 수행되면 판별자 값을 기본값이 덮어씁니다. 자세한 내용은 상속 지원(LINQ to SQL)을 참조하십시오.
.gif "중요") 중요 |
|---|
Table에 추가된 개체는 ID 캐시에 없습니다.ID 캐시는 데이터베이스에서 검색된 개체만 반영합니다.InsertOnSubmit 호출 이후 SubmitChanges가 완료될 때까지 추가된 엔터티는 데이터베이스에 대한 쿼리에 표시되지 않습니다. |
개체 삭제
적절한 Table<TEntity>에서 DeleteOnSubmit(o)을 호출하여 추적된 개체 o를 삭제 대상으로 표시합니다. LINQ to SQL은 EntitySet<TEntity>에서 개체를 제거하는 것을 업데이트 작업으로 간주하며 해당 외래 키 값이 null로 설정됩니다. 작업의 대상(o)은 해당 테이블에서 삭제되지 않습니다. 예를 들어, cust.Orders.DeleteOnSubmit(ord)는 외래 키 ord.CustomerID를 null로 설정하여 cust 및 ord 간의 관계를 끊는 업데이트를 나타냅니다. 이로 인해 ord에 해당하는 행이 삭제되지는 않습니다.
LINQ to SQL은 개체가 해당 테이블에서 삭제될 때(DeleteOnSubmit) 다음 작업을 처리합니다.
SubmitChanges가 호출될 경우 DELETE 작업이 해당 개체에 대해 수행됩니다.
관련 개체가 로드되었는지 여부에 상관없이 제거는 관련 개체에 전파되지 않습니다. 특히 관계 속성을 업데이트하기 위해 관련 개체가 로드되지는 않습니다.
SubmitChanges가 실행된 후 개체는 Deleted 상태로 설정됩니다. 결과적으로 해당 DataContext에서 개체나 개체의 id를 사용할 수 없습니다. DataContext 인스턴스에 의해 유지 관리되는 내부 캐시는 개체가 데이터베이스에서 삭제된 이후에도 검색되거나 새로 추가되는 개체를 제거하지 않습니다.
DataContext에 의해 추적되는 개체에서만 DeleteOnSubmit을 호출할 수 있습니다. Untracked 개체의 경우 DeleteOnSubmit을 호출하기 전에 Attach를 호출해야 합니다. Untracked 개체에서 DeleteOnSubmit를 호출하면 예외가 throw됩니다.
.gif "참고") 참고 |
|---|
테이블에서 개체를 제거하면 LINQ to SQL은 SubmitChanges 시점에 해당 SQL DELETE 명령을 생성합니다.이 작업으로 인해 캐시에서 개체가 제거되거나 관련된 개체에 삭제가 전파되지는 않습니다. 삭제된 개체의 id를 회수하려면 새 DataContext 인스턴스를 사용합니다.관련 개체의 정리를 위해 데이터베이스의 하위 삭제 기능을 사용하거나 관련 개체를 수동으로 삭제할 수 있습니다. 데이터베이스에서와 달리 관련 개체를 특정 순서로 삭제할 필요가 없습니다. |
개체 업데이트
변경 내용에 대한 알림을 확인하여 Updates를 감지할 수 있습니다. 알림은 속성 setter의 PropertyChanging 이벤트를 통해 제공됩니다. 개체에 대한 첫 번째 변경 내용이 알려질 경우 LINQ to SQL은 개체의 복사본을 만들고 Update 문 생성을 위한 후보로 개체를 고려합니다.
INotifyPropertyChanging을 구현하지 않는 개체의 경우 LINQ to SQL은 개체가 처음 구체화될 때 갖고 있던 값의 복사본을 유지 관리합니다. SubmitChanges가 호출되면 LINQ to SQL은 현재 값과 원래 값을 비교하여 개체가 변경되었는지 여부를 확인합니다.
관계 업데이트의 경우 자식에서 부모로의 참조(즉, 외래 키에 해당하는 참조)가 우선권을 가집니다. 반대 방향의 참조(즉, 부모에서 자식으로의 참조)는 선택 사항입니다. 관계 클래스(EntitySet<TEntity> 및 EntityRef<TEntity>)는 일대다 및 일대일 관계에서 양방향 참조가 일관되도록 보장합니다. 개체 모델에 EntitySet<TEntity> 또는 EntityRef<TEntity>가 사용되지 않는 상태에서 역방향 참조가 존재할 경우 관계 업데이트 시에 역방향 참조와 정방향 참조의 일관성을 유지하는 작업을 직접 수행해야 합니다.
필수 참조와 해당 외래 키를 둘 다 업데이트할 경우 서로 일치하는지 확인해야 합니다. SubmitChanges를 호출할 때 두 항목이 동기화되지 않은 경우 InvalidOperationException 예외가 throw됩니다. 외래 키 값 변경을 통해 기본 행 업데이트에 충분히 영향을 줄 수 있지만 개체 그래프의 연결과 관계의 양방향 일관성을 유지 관리하기 위해 참조를 변경해야 합니다.