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 sob uma transação. Uma transação aninhada interna pode interferir na transação externa. Os métodos de substituição de carga podem iniciar uma transação somente depois de determinarem que a operação não está sendo executada em um Transactionarquivo .
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 simultaneidade 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
) eUpdate
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 de incremento automático), oInsertOrder()
método de substituição deverá recuperar a ID gerada pelo banco de dados e definir oOrder.OrderID
membro como essa ID. Da mesma forma, os membros de carimbo de data/hora devem ser atualizados para os valores de carimbo de data/hora gerados pelo banco de dados para garantir que os objetos atualizados sejam consistentes. 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 ansioso, carregamento diferido e SubmitChanges) exigem as substituições para fornecer 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.