LINQ to SQL은 다음 요구 사항을 적용하지 않지만 이러한 요구 사항이 충족되지 않으면 동작이 정의되지 않습니다.
재정의 메서드는 SubmitChanges 또는 Attach를 호출하지 않아야 합니다. LINQ to SQL은 이러한 메서드가 재정의 메서드에서 호출되는 경우 예외를 throw합니다.
재정의 메서드는 트랜잭션을 시작하거나, 커밋하거나, 중지하는 작업에 사용할 수 없습니다. 작업은 SubmitChanges 트랜잭션에서 수행됩니다. 내부 중첩 트랜잭션은 외부 트랜잭션을 방해할 수 있습니다. 부하 오버라이드 메서드는 작업이 Transaction에서 수행되지 않는다고 판단한 후에만 트랜잭션을 시작할 수 있습니다.
오버라이드 메서드는 관련 낙관적 동시성 매핑을 따라야 합니다. 재정의 메서드는 낙관적 동시성 충돌이 발생할 때 ChangeConflictException을(를) 던져야 합니다. LINQ to SQL은 이 예외를 SubmitChanges 포착하여 SubmitChanges에 제공된 옵션을 올바르게 처리할 수 있게 합니다.
만들기(
Insert) 및Update재정의 메서드는 작업이 성공적으로 완료되면 데이터베이스에서 생성된 열의 값을 해당 개체 멤버로 다시 전달해야 합니다.예를 들어 ID 열(기본 키
Order.OrderID)에 매핑된 경우 재정의InsertOrder()메서드는 데이터베이스 생성 ID를 검색하고 멤버를Order.OrderID해당 ID로 설정해야 합니다. 마찬가지로 업데이트된 개체가 일관성을 유지하려면 타임스탬프 멤버를 데이터베이스에서 생성된 타임스탬프 값으로 업데이트해야 합니다. 데이터베이스에서 생성된 값을 전파하지 못하면 데이터베이스와 추적된 개체 간에 불일치가 DataContext발생할 수 있습니다.올바른 동적 API를 호출하는 것은 사용자의 책임입니다. 예를 들어, 업데이트 재정의 메서드에서는 ExecuteDynamicUpdate만 호출할 수 있습니다. LINQ to SQL은 호출된 동적 메서드가 해당 작업과 일치하는지 여부를 검색하거나 확인하지 않습니다. 적용할 수 없는 메서드(예 ExecuteDynamicDelete : 업데이트할 개체)가 호출되면 결과가 정의되지 않습니다.
마지막으로 오버라이드 메서드는 명시된 작업을 수행해야 합니다. 즉시 로드, 지연된 로드 및 SubmitChanges)와 같은 LINQ to SQL 작업의 의미 체계는 명시된 서비스를 제공하려면 재정의가 필요합니다. 예를 들어 데이터베이스의 내용을 확인하지 않고 빈 컬렉션을 반환하는 부하 재정의는 일관성 없는 데이터로 이어질 수 있습니다.