estratégia de Atualização entidade

Question

Há alguma discussão na minha equipe sobre a atualização de dados entidade ea melhor forma de abordá-lo. Esta é uma estrutura de segurança e por isso aqui estão algumas das restrições e idéias.

1. cada mesa na DB tem uma PK que é um guid, isso é necessário para a nossa solução de cluster de vários nós. A idéia é que nós não queremos expor isso em uma entidade a um cliente através de uma API, pois poderia fazer duas coisas,
   1. dar-lhes mais informações que o necessário para o seu trabalho e dando hackers mais informações sobre o sistema.
   2. Suporte pesadelo é que um cliente hardcodes para esse ID de alguma forma e se é preciso alterar os clientes do nosso PK são afetados.

soluções são para expor a chave natual dos itens como objeto papel com um nome único, e Realm, juntamente garantimos singularidade no entanto atualizar qualquer um desses valores é o desafio, porque você precisa especificar os valores antigos e novos para atualização, ou passar dois objetos no original e novo objeto, para que possamos encontrar o caminho para atualização. tipo de bagunçado,

Outra abordagem é fazer uma chave alternativa e ter esta exposto ao cliente que eles possam usá-lo todos eles querem e nós não nos importamos porque não está ligada à nossa PK.

parece que todos estes dias só usa PK como ID para entidades sem problemas, não sei como convencer a nossa equipe de veterns dos velhos tempos de programação timey.

Outra questão é como apoiar atualizações parciais, questão é que você tem entidade com 10 propriedades, 4 coleções, etc ... com um nome + combinação reino e especificar qual propriedade para atualizar em vez de puxar para baixo toda mudança de campo objeto 1 , enviar de volta para a atualização. Eu digo carga preguiçoso as coleções, mas não tenho certeza se a atualização parcial faz sentido.

pensamentos?

Obrigado!

Answer 1

A minha abordagem para uma estrutura de segurança seria assim:

• Dê qualquer coisa no banco de dados de um ID interno (coluna de identidade, seqüência, qualquer que seja o seu suporte de banco de dados. "Nativo coluna id gerado" em Hibernate falar). Eventualmente, você vai precisar dele e retro-fit é um monte de trabalho.

• Se você precisa entregar um ID para o usuário, gerar um número aleatório, verifique se ele já não tenha sido utilizado, conecte-o a uma ID interna e, em seguida, entregá-lo ao usuário. Nunca mão para fora da ID interna e não IDs de uso que podem ser adivinhadas por crackers.

Quanto a atualizações parciais, eles só começam a fazer sentido se você tiver lotes de objetos com muitos atributos. Por 10 atributos, eu diria " prematura otimização ."

Answer 2

Use chave natural se você precisa expor id para o cliente. Não é tão fácil de implementar, mas essa é a maneira correta.

Você poderia fornecer pouco mais detalhes sobre essas atualizações parciais? Eu não consegui-lo. : /

Answer 3

Usando GUIDs em cada mesa como um sons de chave primária como a pedir sarilhos. Eu não vi essa abordagem levado para qualquer lugar a menos que eu estou realmente entendendo mal de você. Porque não basta emitir um UID para cada usuário e trabalho com o UID?

Esta abordagem é mais comum em todas as empresas. O UID não é PII assim que você é bem legal como foi a partir de um ponto de vista da segurança.