Un oggetto dovrebbe conoscere il proprio ID?

Risposta breve: l'inclusione dell'identificatore dell'oggetto nell'oggetto è un must se verrà indicato.

Per uno scenario in cui prevedi di utilizzare una raccolta di oggetti e hai piani per fare riferimento a un singolo oggetto / entità, è necessario includere l'identificatore. Tuttavia, potrebbero esserci casi in cui la chiave / identificatore naturale come DateTime può soddisfare artificialmente tale esigenza.

Inoltre, potresti avere il tuo DTO come contenitore leggero del tuo oggetto, che può saltare / includere l'identificatore dell'oggetto in sé. Tutte queste scelte sono in realtà dipendono dai casi e dalle esigenze di utilizzo della tua azienda .

Modifica: se vuoi identificare il tuo oggetto devi avere un identificatore. Questo identificatore può essere un ID surrogato, data-ora, guida, ecc. In pratica, qualsiasi cosa che identifichi il tuo oggetto dagli altri in un modo unico.

Nel tentativo di lasciare la mia risposta astratta come la tua domanda, penso che tu abbia effettivamente risposto alla tua stessa domanda.

Un oggetto dovrebbe conoscere il proprio ID se necessario.

Un oggetto non dovrebbe conoscere il suo ID (o che ne ha persino uno) se non è necessario.

Come hai sottolineato, ci sono casi in cui è scomodo o non necessario per l'oggetto conservare o sapere se il suo ID. Ma ci sono altri casi in cui è più conveniente che l'oggetto sia a conoscenza del suo ID. Codifica gli oggetti in base al loro utilizzo.

È abbastanza comune includere l'ID, ma è anche comune usare dizionari, cioè le strutture dati in cui ogni oggetto è associato al suo ID in modo da poter facilmente recuperare questo oggetto conoscendo l'ID corrispondente, ma l'oggetto non lo fa lo so.

Ad esempio, se stai creando un'API con due metodi:

• link

  Carica l'elenco degli ID dei prodotti.

• link

  Carica un prodotto dell'ID 452.

Quindi non è necessario inviare nuovamente l'ID 452 nella risposta JSON della seconda richiesta. L'utente dell'API conosce già l'ID.

Penso che questo sia soggettivo e dipende dal tuo design.

Per lo più questo sembra essere un design proveniente da un record attivo . In una registrazione attiva, l'entità ha metodi per eseguire operazioni di database e, pertanto, deve conoscere anche l'identificatore del database.

Quando usi altri modelli come un repository con un data mapper l'archiviazione di questi dati nell'oggetto diventa inutile e forse inappropriata.

Prendi ad esempio un oggetto Person . Mi viene dato un nome che può o non può essere unico all'interno di una famiglia. Dato che la popolazione è cresciuta, i nomi più grandi non sono più unici e quindi abbiamo creato identificatori surrogati per un sistema sempre più grande. Esempi di questi includono: la mia patente di guida e il numero di previdenza sociale. Non sono nato con un ID, tutti questi ID devono essere richiesti.

La maggior parte di questi non rende valide le chiavi / id principali per il software, in quanto non sono universali. Almeno non al di fuori del loro sistema specifico, ovviamente un SSN è unico e coerente per l'Amministrazione della sicurezza sociale. Dato che non siamo generalmente i fornitori di queste informazioni, non le chiamerebbero un id , ma piuttosto i dati che rappresentano, ad es. %codice%. A volte persino contiene l'oggetto composto completo come SSN che potrebbe contenere tutte le informazioni della licenza del conducente.

Tutti gli ID generali sono quindi chiavi surrogate nel sistema e potrebbero essere sostituiti con riferimenti di memoria, contenenti solo ID per facilitare la ricerca e la persistenza dei record.

Poiché un DriversLicense non è un dato concettuale, dubito che esso (in genere) appartenga all'oggetto, in quanto non proviene dal dominio. Piuttosto dovrebbe essere mantenuto al suo scopo che è quello di identificare un oggetto che non ha altro modo di rappresentare un'identità unica. Questo potrebbe essere fatto in un repository / raccolta con facile.

Nel software se devi rappresentare l'oggetto come una lista, o persistere, puoi semplicemente farlo dall'oggetto repository / collection, o qualche altro oggetto associato a questo. Passando al Data Mapper (se è separato), puoi semplicemente passare id .

Dichiarazione di non responsabilità : non ho ancora provato a creare un sistema che non contenga l'id all'interno dell'entità e possa quindi dimostrarmi sbagliato.

Come ha notato GlenH7 in un commento, è una buona domanda, perché sfida ciò che molte persone danno per scontato. La mia opinione è che, anche se lasciare l'id out possa sembrare concettualmente puro, la cosa pragmatica da fare sarebbe mantenere l'id con l'oggetto su quanti più livelli del sistema possibile. Costa poco, ma può tornare utile quando le cose cominciano a crollare.

Un'entità potrebbe non aver bisogno di sapere che è id, proprio come una persona non ha bisogno di conoscere il suo numero di identificazione personale, numero di patente di guida e qualsiasi altro identificatore che potrebbe essere in uso nella vostra posizione. Potresti sicuramente farne a meno la maggior parte del tempo. È saggio comunque portare con sé una sorta di identificazione, per ogni evenienza.

Lo stesso si può dire di un oggetto. A prescindere dalle complessità del livello di accesso ai dati, l'oggetto alla fine esegue il mapping su una determinata voce del database. Questa voce potrebbe essere identificabile in modo univoco dall'ID dell'oggetto. Se è così, allora preferirei avere queste informazioni a mia disposizione in qualsiasi momento, indipendentemente dal fatto che io stia eseguendo il debug di qualche codice UI, numero di crunch nel livello aziendale, il repository stesso o un sistema dipendente attraverso un webservice. O se sto sfogliando i log degli errori per quella materia.

Nel tuo caso, se stai solo recuperando i dati dal db e spingendoli attraverso il webservice, lasciare l'id out potrebbe essere la cosa giusta da fare. Semplicemente non credo che abbia più senso che tenerlo nel caso generale.

Hai ragione, non è necessario memorizzare l'id nell'oggetto, purché sia necessario conoscerlo solo nel contesto del repository.

La situazione cambia quando si passa l'oggetto al codice fuori da quel contesto, codice che non ha richiesto l'oggetto da id (e quindi non lo conosce ancora), ma ha bisogno dell'ID per qualsiasi scopo (ad esempio per inserirlo in un elenco di ID che verranno richiesti dal repository in seguito, da un altro codice).

In questa situazione, hai due opzioni:

• introduce un nuovo argomento di funzione 'id' nell'intera catena di funzioni tra il contesto del repository e la funzione in cui è necessario l'id

• include l'id nell'oggetto

Nella maggior parte di questi casi, la soluzione migliore è la memorizzazione dell'ID all'interno dell'oggetto. Ridurrà anche le modifiche al codice quando l'ID è necessario in luoghi imprevisti, inoltre potrebbe essere utile con il debug a volte.

Ecco perché lo faccio quando lo faccio.