Limitazioni del pattern Mappa di identità

Is this last assumption right?

Sì, che altro pensi?

Within DDD there is the tendency where Entity equality is based on having the same id not the same memory address.

Questo non ha nulla a che fare con DDD. "Oggetti di database" hanno sempre bisogno di una chiave univoca o di un ID, in genere non esiste un "indirizzo di memoria" da memorizzare nel DB per distinguerli. Quindi c'è sempre un ID disponibile, che può essere usato anche per controllare l'uguaglianza per gli oggetti in memoria, indipendentemente dall'usare il modello di mappa di identità o meno. Avendo una "mappa di identità" in atto e assunta nel tuo contesto, puoi essere sicuro al 100% che nessun oggetto può essere creato senza prima controllare la "mappa di identità", è infatti possibile sostituire il test di identificazione con un test di indirizzo di memoria, ma in pratica i vantaggi sono IMHO molto piccoli.

I always had the "feeling" of having a unique instance of my objects*

Onestamente, avere un "sentimento" su qualcosa come questo è IMHO una parola diversa per non sapere come funziona qualcosa. E sì, usare un framework senza sapere cosa succede è sempre "pericoloso" (preferisco il termine "a rischio di errore"). Per essere più specifici: quando si utilizza un ORM, è necessario informarsi accuratamente se l'ORM fornisce già qualcosa come una "Mappa di identità" o "Cache oggetto" e quali caratteristiche fornisce esattamente.

Should I normally be concerned about my objects having multiple instances?

Ciò dipende in larga misura dall'applicazione gentile che si sta per scrivere, dal tipo di transazioni commerciali, dal numero di record coinvolti, dal tipo di query e così via. È perfettamente possibile scrivere applicazioni che creano oggetti dal database in un ambito locale, manipolarli e scriverli indietro, senza preoccuparsi di altre parti dell'applicazione che potrebbero avere una seconda copia dello stesso "oggetto db" allo stesso tempo . Ma se hai bisogno che la stessa informazione nella tua applicazione sia sempre sincronizzata, questa potrebbe non essere la strada da percorrere.

Or even being out of sync with the database?

Di nuovo, questo dipende. Per molte applicazioni non si può nemmeno evitare che le cose vadano fuori sincrono, almeno per un breve periodo (si pensi a uno scenario in cui un secondo client cambia il DB sulla rete, senza alcuna meccanica "push"). Ma per quanto tempo è tollerabile e se alcune transazioni devono essere sicure al 100% di avere i dati della versione più recente, dipende dalle tue esigenze.

La tua comprensione è corretta.

Le mappe di identità hanno lo scopo di aiutare i programmatori orientati agli oggetti a gestire i problemi di gestione dello stato. Scrivono programmi imperativi che, se non vengono presi in considerazione, potrebbero finire per avere aree diverse del programma che trattano una copia obsoleta di un oggetto persistibile.

Considera i problemi di concorrenza di base. Alice tira su un particolare record sul suo schermo. Bob fa lo stesso un attimo dopo. Alice aggiorna la sua copia e salva, poi Bob lo fa. Le modifiche di Alice sono perse se il programma non considera questo scenario.

Ora prendi in considerazione la stessa cosa ma entro i confini di un singolo programma. Un'area nebulosa A del programma carica un oggetto in memoria mentre un'altra area nebulosa B fa lo stesso. L'area A aggiorna la sua copia, quindi l'area B. È sempre la progettazione del programma che consente problemi di concorrenza interna.

Nel mondo imperativo il cambiamento di stato è dilagante. La mappa delle identità è un modello per alleviare i problemi di concorrenza in memoria. Nei programmi progettati per evitare problemi di concorrenza, le mappe di identità non sono necessarie. Il problema è che il percorso del codice imperativo può essere imprevedibile e ci si deve chiedere se possa esserci un problema di concorrenza e guardarlo da vicino - nel caso .

Questo sarebbe meno di un problema nella programmazione funzionale perché c'è un'enfasi sull'avere dati immutabili. Tutto è rappresentato in strutture di dati. Ogni pezzo di dati viene rappresentato una sola volta ( SPOT ) come parte di una più ampia astrazione di dati che rappresenta l'insieme di tutti i dati nel suo mondo. Le mappe di identità sono completamente inutili. Oppure, da un punto di vista, si potrebbe dire che l'intero fondamento della programmazione funzionale si basa sull'uso di mappe di identità - un'unica grande sfera dello stato mondiale.

La mappa di identità deve essere portata per richiesta o per modulo, non open-ended nell'ambito. La memoria dovrebbe quindi essere proporzionale all'utilizzo simultaneo (e forse anche al timeout delle sessioni scadute) e non dovrebbe crescere oltre.

Digitare la mappa di identità per identità del database (ad es. chiave primaria) è la cosa migliore. Altre persone parlano dell'uso della chiave aziendale (ad esempio nome, indirizzo, DOB) come chiave ma quell'approccio presenta deficit significativi - ad es. non corrisponde più quando cambia l'indirizzo.

Identity Map è un concetto separato dal blocco: gli utenti concorrenti dovrebbero avere istanze separate degli oggetti potenzialmente modificabili; senza istanze distinte, è difficile rappresentare le loro modifiche separate / o tenere traccia del "numero di versione" del blocco ottimistico in cui si si aspetta di salvare.