開發人員覆寫預設行為的責任
LINQ to SQL 不會強制要求下列需求，但是如果未滿足這些需求，就不會定義行為。
覆寫方法不得呼叫 SubmitChanges 或 Attach。 如果是以覆寫方法呼叫這些方法，則 LINQ to SQL 會擲回例外狀況。
覆寫方法不可以用來啟動、認可或停止異動。 SubmitChanges 作業是在交易下執行。 而內部巢狀交易會干擾外部交易。 只有在載入覆寫方法判斷作業未在 Transaction 中執行之後，載入覆寫方法才可以啟動異動。
需要有覆寫方法，才能遵循適用的開放式並行存取 (Optimistic Concurrency) 對應。 開放式並行存取發生衝突時，覆寫方法應該會擲回 ChangeConflictException。 LINQ to SQL 會快取這個例外狀況，讓您可以正確處理 SubmitChanges 上提供的 SubmitChanges 選項。
作業順利完成時，則需要建立 (
Insert) 和Update覆寫方法將資料庫所產生的資料行值送回給對應的物件成員。例如，如果
Order.OrderID是對應至識別資料行 (autoincrement 主索引鍵)，則InsertOrder()覆寫方法必須擷取資料庫產生的 ID，並將Order.OrderID成員設定為該 ID。 同樣地，必須將時間戳記成員更新為資料庫產生的時間戳記值，以確定更新的物件一致。 散佈資料庫產生的值失敗，會造成資料庫與 DataContext 追蹤的物件不一致。使用者必須負責叫用 (Invoke) 正確的動態 API。 例如，在更新覆寫方法中，您只能呼叫 ExecuteDynamicUpdate。 LINQ to SQL 不會偵測或驗證所叫用的動態方法是否符合適用的作業。 如果呼叫不適用的方法 (例如，對要更新的物件呼叫 ExecuteDynamicDelete)，則會產生無法定義的結果。
最後，需要有覆寫方法才能執行陳述的作業。 LINQ to SQL 作業 (例如積極式載入、延後載入和 SubmitChanges) 的語意需要有覆寫，才能提供所述服務。 例如，只傳回空集合而不檢查資料庫內容的載入覆寫，可能會導致資料不一致。