Un oggetto dovrebbe conoscere il proprio ID?

obj.idsembra abbastanza comune e sembra anche rientrare nel raggio di qualcosa che un oggetto potrebbe conoscere su se stesso. Mi trovo a chiedermi perché il mio oggetto dovrebbe conoscere il proprio ID?

Non sembra avere un motivo per averlo? Uno dei motivi principali della sua esistenza è recuperarlo, quindi i miei repository devono conoscerlo e quindi utilizzarlo per l'interazione con il database.

Una volta ho anche riscontrato un problema in cui volevo serializzare un oggetto su JSON per un'API RESTful in cui l'id non sembrava adattarsi al payload, ma solo l'URI e includerlo nell'oggetto rendeva questo più difficile.

Un oggetto dovrebbe sapere il proprio id? perché o perché no?

aggiornamento : Termini

1. id: attributo identificatore su un oggetto. in termini di database, una chiave surrogata non una chiave naturale.
2. Oggetto: un'entità, o altrimenti identificabile in modo univoco all'interno del sistema.

Risposta breve: l' inclusione dell'identificatore di oggetto all'interno dell'oggetto è indispensabile se si intende fare riferimento.

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

Inoltre, potresti avere il tuo DTO come un contenitore leggero del tuo oggetto, che può saltare / includere l'identificatore dell'oggetto in sé. Davvero tutte queste scelte dipendono davvero dai casi d'uso e dalle esigenze della tua azienda .

Modifica: se vuoi identificare il tuo oggetto devi avere un identificatore. Quell'identificatore può essere un ID surrogato, data-ora, guida, ecc ... fondamentalmente, tutto ciò che identifica 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 anche uno) se non è necessario.

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

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

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

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

  Carica l'elenco di ID dei prodotti.

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

  Carica un prodotto con 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.

Principalmente, però, questo sembra essere un progetto che proviene da un record attivo . In un record attivo la tua entità ha metodi per eseguire operazioni sul database e quindi deve anche conoscere l'identificatore del database.

Quando si utilizzano altri modelli come un repository con un mappatore di dati che memorizza questi dati nell'oggetto diventa inutile e forse inappropriato.

Prendi ad esempio un Personoggetto. Mi viene dato un nome che può essere o non essere unico all'interno di una famiglia. Poiché la popolazione è cresciuta, i nomi più grandi non sono più univoci e così abbiamo creato identificatori surrogati per sistemi sempre più grandi. Esempi di questi includono: la mia patente di guida e il numero di previdenza sociale. Non sono nato assegnato un ID, tutti questi ID devono essere richiesti.

La maggior parte di questi non fornisce buone chiavi / ID primari 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 previdenza sociale. Dal momento che non siamo generalmente i fornitori di queste informazioni, non li chiameresti idma piuttosto i dati che rappresentano, ad es SSN. A volte contiene persino l'oggetto composto completo, ad esempio un oggetto DriversLicenseche può contenere tutte le informazioni contenute nella patente di guida.

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

Dato che an idnon è un pezzo di dati concettuali, dubito che (generalmente) 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 / collection con facilità.

Nel software, se è necessario rappresentare l'oggetto come un elenco o persisterlo, è possibile farlo semplicemente dall'oggetto repository / collection o da qualche altro oggetto associato. Quando passi al Data Mapper (se è separato), puoi semplicemente passare .update( id, obj ).

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

Come ha osservato GlenH7 in un commento, è una buona domanda, perché sfida ciò che molte persone danno per scontato. La mia opinione su ciò, tuttavia, è che anche se lasciare fuori l'id potrebbe sembrare concettualmente puro, la cosa pragmatica da fare sarebbe quella di mantenere l'ID con l'oggetto attraverso il maggior numero possibile di strati del sistema. Costa poco, ma può tornare utile quando le cose iniziano a guastarsi.

Un'entità potrebbe non aver bisogno di sapere il suo ID, proprio come una persona non ha bisogno di conoscere il suo numero di identificazione personale, il numero di patente di guida o qualsiasi altro identificatore che potrebbe essere in uso nella tua posizione. Potresti sicuramente farne a meno per la maggior parte del tempo. È saggio tuttavia portare un qualche tipo di identificazione su di te, per ogni evenienza.

Lo stesso si può dire di un oggetto. Indipendentemente dalle complessità del livello di accesso ai dati, l'oggetto alla fine si associa a una determinata voce del database. Questa voce potrebbe essere identificabile in modo univoco solo dall'ID dell'oggetto. In tal caso, preferirei avere queste informazioni disponibili in qualsiasi momento, indipendentemente dal fatto che stia eseguendo il debug di un codice UI, il crunching dei numeri nel livello aziendale, il repository stesso o un sistema dipendente attraverso un servizio web. 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 servizio web, lasciare l'id fuori potrebbe essere la cosa giusta da fare. 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 al di fuori di quel contesto, codice che non ha richiesto l'oggetto per id (e quindi non lo conosce ancora), ma ha bisogno dell'id per qualsiasi scopo (ad es. Per inserirlo in un elenco di ID che verranno richiesti dal repository in un secondo momento, con un altro codice).

In quella situazione, hai due opzioni:

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

• includere l'id nell'oggetto

Nella maggior parte di questi casi, archiviare l'id all'interno dell'oggetto sarà la soluzione migliore. 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.