Estados e controle de alterações de objeto
Os objetos LINQ to SQL de sempre participam em qualquer estado. Por exemplo, quando LINQ to SQL cria um novo objeto, o objeto está no estado de Unchanged. Um novo objeto que você mesmo criar for desconhecido para DataContext e está no estado de Untracked. Após a execução com êxito de SubmitChanges, todos os objetos conhecidos a LINQ to SQL estão no estado de Unchanged. (A única exceção é representada por aqueles que foram excluídas com êxito de base de dados, que estão no estado de Deleted e inutilizável que a instância de DataContext .)
Estados de objeto
A tabela a seguir lista os estados possíveis para objetos de LINQ to SQL.
| Estado | Descrição |
|---|---|
Untracked |
Um objeto não rastreado por LINQ to SQL. Os exemplos incluem o seguinte: - Um objeto não consultado com DataContext atual (como um objeto criado). - Um objeto criado com a desserialização - Um objeto consultado com DataContext diferente. |
Unchanged |
Um objeto retornado usando DataContext atual e não conhecido para ter sido alterado desde que ele foi criado. |
PossiblyModified |
Um objeto que é anexado a um DataContext. Para ter mais informações, consulte Recuperação de dados e operações de CUD em aplicativos de N Camadas (LINQ to SQL). |
ToBeInserted |
Um objeto não recuperado usando DataContextatual. Isso faz com que um base de dados INSERT durante SubmitChanges. |
ToBeUpdated |
Um objeto conhecido para ter sido alterado desde que ele foi recuperado. Isso faz com que um base de dados UPDATE durante SubmitChanges. |
ToBeDeleted |
Um objeto marcado para exclusão, causando um base de dados DELETE durante SubmitChanges. |
Deleted |
Um objeto que é excluído na base de dados. Esse estado é final e não permite transições adicionais. |
Inserindo objetos
Você pode solicitar Inserts explicitamente usando InsertOnSubmit. Como alternativa, o LINQ to SQL pode inferir Inserts localizando os objetos conectados a um dos objetos conhecidos que devem ser atualizados. Por exemplo, se você adicionar um objeto de Untracked a EntitySet<TEntity> ou definir EntityRef<TEntity> a um objeto de Untracked, você tornará o objeto Untracked alcançável por objetos rastreadas no gráfico. Ao processar SubmitChanges, o LINQ to SQL percorre os objetos rastreadas e descobre todos os objetos acessíveis persistentes que não são controlados. Esses objetos são candidatos para inserção na base de dados.
Para classes em uma hierarquia de herança, InsertOnSubmit(o) também define o valor do membro designado como o discriminador para coincidir com o tipo de objeto o. No caso de um tipo que corresponde ao valor padrão de discriminador, esta ação faz com que o valor de discriminador a ser substituído com o valor padrão. Para obter mais informações, consulte Suporte de herança.
Importante
Um objeto adicionado a Table não estiver no cache de identidade. O cache de identidade reflete somente o que é recuperado de base de dados. Após uma chamada a InsertOnSubmit, a entidade adicionada não aparece em consultas na base de dados até que SubmitChanges está concluída com êxito.
Excluindo objetos
Você marca um objeto acompanhado o para exclusão chamando DeleteOnSubmit() no Table<TEntity>apropriado. O LINQ to SQL considera a remoção de um objeto de EntitySet<TEntity> como uma operação de atualização, e o valor de chave estrangeira correspondente é definido como nulo. O destino da operação (o) não é excluído da tabela. Por exemplo, cust.Orders.DeleteOnSubmit(ord) indica uma atualização onde a relação entre cust e ord está separada definindo a chave estrangeira ord.CustomerID para nulo. Não faz com que a exclusão da linha que corresponde a ord.
O LINQ to SQL executa o processamento seguinte quando um objeto é excluído (DeleteOnSubmit) de sua tabela:
Quando SubmitChanges é chamado, uma operação de
DELETEé executada para esse objeto.Remoção não é propagada a objetos relacionados independentemente se eles são carregados. Especificamente, os objetos relacionados não são carregados atualizar a propriedade de relacionamento.
Após a execução bem-sucedida de SubmitChanges, os objetos são definidos no estado de
Deleted. Como resultado, você não pode usar o objeto ou seuidnesse DataContext. O cache interno mantido por uma instância de DataContext não elimina os objetos que são recuperados ou adicionados como novas, mesmo após os objetos foram excluídos na base de dados.
Você pode chamar DeleteOnSubmit somente em um objeto controlado por DataContext. Para um objeto de Untracked , você deve chamar Attach antes de chamar DeleteOnSubmit. A chamada DeleteOnSubmit em um objeto de Untracked gerencie uma exceção.
Observação
Remover um objeto de uma tabela com LINQ to SQL para gerar um comando DELETE correspondente do SQL na altura de SubmitChanges. Esta ação não remove o objeto de cache ou não propaga a exclusão a objetos relacionados.
Para recuperar id de um objeto excluído, use uma nova instância de DataContext . Para limpeza de objetos relacionados, você pode usar o recurso em cascata de excluir da base de dados, ou então excluir manualmente os objetos relacionados.
Os objetos relacionados não precisam ser excluídos em qualquer encomenda especial (em oposição na base de dados).
Atualizando objetos
Você pode detectar Updates observando notificações de alterações. As notificações são fornecidas com o evento de PropertyChanging em definidores de propriedade. Quando LINQ to SQL é notificado da primeira alteração em um objeto, cria uma cópia do objeto e considera o objeto um candidato para gerar uma instrução de Update.
Para objetos que não implementam INotifyPropertyChanging, o LINQ to SQL mantém uma cópia dos valores que objetos tinham quando foram materializados primeiro. Quando você chama SubmitChanges, o LINQ to SQL compara os valores atuais e originais para decidir se o objeto foi alterado.
Para atualizações para relações, a referência de filho ao pai (ou seja, a referência que corresponde à chave estrangeira) é considerada a autoridade. A referência na direção invertida (isto é, pai para o filho) é opcional. As classes de relacionamento (EntitySet<TEntity> e EntityRef<TEntity>) garantem que as referências bidirecionais são consistentes para para muitos e relacionamento um-para-um. Se o modelo de objeto não usa EntitySet<TEntity> ou EntityRef<TEntity>, e se a referência invertido estiver presente, é de sua responsabilidade mantê-la consistente com a referência direta ao relacionamento é atualizada.
Se você atualizar a referência ambos necessário e a chave estrangeira correspondente, você deve certificar-se que concordam. Uma exceção de InvalidOperationException é lançada se os dois não são sincronizados momento em que você chamar SubmitChanges. Embora as alterações de valor de chave estrangeira são suficientes para afetar uma atualização de linha base, você deve alterar a referência para manter a conectividade do grafo de objeto e consistência bidirecional relações.