Responsabilidades do desenvolvedor na substituição do comportamento padrão

O LINQ to SQL não impõe os seguintes requisitos, mas o comportamento é indefinido se esses requisitos não forem satisfeitos.

• O método predominante não deve chamar SubmitChanges ou Attach. LINQ to SQL lança uma exceção se esses métodos são chamados em um método de substituição.

• Os métodos de substituição não podem ser usados para iniciar, confirmar ou interromper uma transação. A SubmitChanges operação é realizada no contexto de uma transação. Uma transação interna aninhada pode interferir na externa. Os métodos de sobrecarga podem iniciar uma transação somente depois de determinarem que a operação não está sendo executada em um Transaction.

• Espera-se que os métodos de substituição sigam o mapeamento de simultaneidade otimista aplicável. Espera-se que o método de substituição lance um ChangeConflictException quando ocorrer um conflito de concorrência otimista. O LINQ to SQL captura essa exceção para que você possa processar corretamente a SubmitChanges opção fornecida no SubmitChanges.

• Espera-se que os métodos Create (Insert) e Update override façam fluir de volta os valores das colunas geradas pelo banco de dados para os membros do objeto correspondentes quando a operação for concluída com êxito.

  Por exemplo, se Order.OrderID for mapeado para uma coluna de identidade (chave primária autoincremento), então o método de substituição InsertOrder() deverá recuperar a ID gerada pelo banco de dados e definir o membro Order.OrderID como essa ID. Da mesma forma, os campos de carimbo de data/hora devem ser atualizados com os valores gerados pelo banco de dados, garantindo que os objetos atualizados mantenham consistência. A falha ao propagar os valores gerados pelo banco de dados pode causar uma inconsistência entre o banco de dados e os objetos rastreados pelo DataContext.

• É responsabilidade do usuário invocar a API dinâmica correta. Por exemplo, no método de substituição de atualização, somente o ExecuteDynamicUpdate pode ser chamado. O LINQ to SQL não deteta nem verifica se o método dinâmico invocado corresponde à operação aplicável. Se um método inaplicável for chamado (por exemplo, ExecuteDynamicDelete para que um objeto seja atualizado), os resultados serão indefinidos.

• Finalmente, espera-se que o método de substituição execute a operação declarada. A semântica das operações LINQ to SQL, como carregamento imediato, carregamento adiado e SubmitChanges) exigem que as substituições forneçam o serviço declarado. Por exemplo, uma substituição de carga que apenas retorna uma coleção vazia sem verificar o conteúdo no banco de dados provavelmente levará a dados inconsistentes.

Ver também

• Personalizando operações de inserção, atualização e exclusão