Um objeto deve saber seu próprio ID?

obj.idparece bastante comum e também parece estar dentro do alcance de algo que um objeto poderia saber sobre si mesmo. Eu me pergunto por que meu objeto deve saber seu próprio ID?

Não parece ter um motivo para tê-lo? Um dos principais motivos de sua existência é recuperá-lo e, portanto, meus repositórios precisam conhecê-lo e, portanto, usá-lo para interação com o banco de dados.

Uma vez, também encontrei um problema em que queria serializar um objeto para JSON para uma API RESTful em que o ID não parecia caber na carga, mas apenas o URI e a inclusão no objeto tornaram isso mais difícil.

Um objeto deve saber sua própria identificação? por que ou por que não?

update : Termos

1. id: atributo identificador em um objeto. em termos de banco de dados, uma chave substituta não é uma chave natural.
2. Objeto: uma entidade ou outro objeto identificável de forma única no sistema.

Resposta curta: Incluir um identificador de objeto dentro do objeto é obrigatório se for encaminhado.

Para um cenário em que você planeja usar uma coleção de objetos e tem planos para indicar um objeto / entidade individual, o identificador deve ser incluído. No entanto, pode haver casos em que chave / identificador natural como DateTimepossa atender artificialmente a essa necessidade.

Além disso, você pode ter seus DTOs como um contêiner leve do seu objeto, que pode pular / incluir o identificador de objeto em si. Realmente, todas essas opções dependem realmente dos casos e necessidades de uso de negócios .

Editar: se você deseja identificar seu objeto, precisa de um identificador. Esse identificador pode ser um ID substituto, data e hora, guia, etc ... basicamente, qualquer coisa que identifique seu objeto de outras pessoas de uma maneira única.

Na tentativa de deixar minha resposta tão abstrata quanto sua pergunta, acho que você realmente respondeu sua própria pergunta.

Um objeto deve saber seu próprio ID, se necessário.

Um objeto não deve saber seu ID (ou mesmo o possui) se não precisar.

Como você apontou, há casos em que é inconveniente ou desnecessário para o objeto reter ou saber se seu ID. Mas há outros casos em que é mais conveniente que o objeto esteja ciente de seu ID. Codifique seus objetos conforme apropriado para o uso deles.

É bastante comum incluir o ID, mas também é comum usar dicionários, ou seja, as estruturas de dados em que cada objeto está associado ao seu ID, de maneira que você possa recuperar facilmente esse objeto sabendo o ID correspondente, mas o objeto não sabe isto.

Por exemplo, se você estiver criando uma API com dois métodos:

• http://api.example.com/products/

  Carrega a lista de IDs de produtos.

• http://api.example.com/product/452/

  Carrega um produto com o ID 452.

Então você não precisa reenviar o ID 452 na resposta JSON da segunda solicitação. O usuário da API já conhece o ID.

Eu acho que isso é subjetivo e depende do seu design.

Principalmente, embora pareça ser um design que vem de um registro ativo . Em um registro ativo, sua entidade possui métodos para executar operações de banco de dados e, portanto, também deve saber seu identificador de banco de dados.

Ao usar outros padrões, como um repositório com um mapeador de dados que armazena esses dados no objeto, torna-se desnecessário e talvez inapropriado.

Tomemos, por exemplo, um Personobjeto. Recebo um nome que pode ou não ser único em uma família. À medida que a população cresce, nomes maiores não são mais exclusivos e, por isso, criamos identificadores substitutos para sistemas cada vez maiores. Exemplos disso incluem: minha carteira de motorista e número de segurança social. Não nasci atribuído um ID, todos esses IDs devem ser solicitados.

A maioria deles não fornece boas chaves / IDs primárias para software, pois não são universais. Pelo menos não fora de seu sistema específico, obviamente um SSN é único e consistente para a Administração de Seguridade Social. Como geralmente não somos os fornecedores dessas informações, você não os chamaria, idmas sim os dados que eles representam, por exemplo SSN. Às vezes, até contém o objeto composto completo, como um DriversLicenseque pode conter todas as informações da carteira de motorista.

Todos os IDs gerais são, portanto, chaves substitutas no sistema e podem ser substituídos por referências na memória, contendo apenas IDs para facilitar a procura e a persistência de registros.

Como um idnão é um dado conceitual, duvido que ele (geralmente) pertença ao objeto, pois não vem do domínio. Em vez disso, ele deve ser mantido com o objetivo de identificar um objeto que não tem outra maneira de representar uma identidade única. Isso pode ser feito em um repositório / coleção com facilidade.

No software, se você precisar representar o objeto como uma lista ou persistir, basta fazê-lo no objeto de repositório / coleção ou em algum outro objeto associado a ele. Ao passar para o Data Mapper (se estiver separado), você pode simplesmente passar .update( id, obj ).

Isenção de responsabilidade : ainda não tentei criar um sistema que não contenha o ID na entidade e, portanto, possa me provar errado.

Como GlenH7 observou em um comentário, é uma boa pergunta, porque desafia o que muitas pessoas dão como certo. Minha opinião, no entanto, é que, mesmo que deixar o id de fora possa parecer conceitualmente puro, a coisa pragmática a fazer seria manter o id com o objeto em tantas camadas do sistema quanto possível. Custa pouco, mas pode ser útil quando as coisas começam a quebrar.

Uma entidade pode não precisar saber seu ID, assim como uma pessoa não precisa saber seu número de identificação pessoal, número da carteira de motorista nem qualquer outro identificador que possa estar em uso no seu local. Você certamente poderia ficar sem ele na maioria das vezes. É sábio, no entanto, levar algum tipo de identificação em você, apenas por precaução.

O mesmo pode ser dito de um objeto. Independentemente das complexidades da camada de acesso a dados, o objeto é mapeado para uma determinada entrada do banco de dados. Esta entrada pode ser identificável exclusivamente pelo ID do objeto. Nesse caso, eu preferiria ter essas informações disponíveis a qualquer momento, independentemente de eu estar depurando algum código da interface do usuário, processamento de números na camada de negócios, o próprio repositório ou um sistema dependente em um serviço da web. Ou se eu estou navegando nos logs de erro para esse assunto.

No seu caso, se você está apenas buscando dados do banco de dados e enviando-os pelo serviço da web, deixar o ID de fora pode ser a coisa certa a fazer. Só não acredito que faça mais sentido do que mantê-lo no caso geral.

Você está certo, não precisa armazenar o ID no objeto, contanto que você só precise conhecê-lo no seu contexto de repositório.

A situação muda quando você passa o objeto para codificar fora desse contexto, código que não solicitou o objeto pelo ID (e, portanto, ainda não o conhece), mas precisa do ID para qualquer finalidade (por exemplo, colocá-lo em uma lista de IDs que serão solicitados posteriormente ao repositório por outro código).

Nessa situação, você tem duas opções:

• introduzir um novo argumento de função 'id' em toda a cadeia de funções entre o contexto do repositório e a função em que o id é necessário

• inclua o ID no objeto

Na maioria desses casos, armazenar a identificação dentro do objeto será a melhor solução. Também reduzirá as alterações de código quando o ID for necessário em locais imprevistos, além de poder ser útil na depuração às vezes.

É por isso que faço quando faço.