Come dovrebbe essere gestita l'identificazione degli oggetti?

Question

Come dovrebbe essere gestita l'identificazione degli oggetti?

#1 da (1 voti)

2

Ho un'applicazione java / swing nella struttura MVC (si spera buona). Ecco una panoramica delle mie classi di modelli:

Unoopiùworkerspuòfunzionareadunworkinglocationeunworkerpuòfunzionarea%diversoworkinglocations(nonallostessotempo,ovviamente).Aworkerpuòaverediversitipididateassegnati.Ilworkinglocationhaunelencodituttiisuoiworkers.Ognidatehaunriferimentoalsuoworker.Tuttiglioggettidelmodellosonomodificabili.

PerscopidigestionehoimplementatounDatabase.javacheèresponsabileperl'archiviazionedelleclassidelmodellonelleclassidiraccoltajavaealprogrammachiusurasalvandotuttiglioggettiinunfilexml(iouso java simple xml framework per questa attività). Ha i seguenti tre elenchi: List<Working location> , List<Worker> e List<Date> . Quindi la procedura è:

Carica il file xml all'avvio del programma
Aggiungi / modifica / rimuovi oggetti modello in / in / da database (lavorando con le raccolte di Database.java
Salva tutti gli oggetti modello dalle raccolte Database nel file xml all'uscita programma

(Se c'è qualcosa di brutto nel mio modo di pensare fino ad ora, per favore dimmi un modo migliore! Lo apprezzerò molto.)

Ecco la domanda:
Qual è il modo corretto di identificare gli oggetti modello?

Posso pensare a due possibilità:

Utilizza riferimenti a oggetti
- (+) Non esiste un codice aggiuntivo per gestire la generazione di nuovi ID univoci
- (-) "Everyone" può modificare gli oggetti (perché questo è un progetto privato "Everyone" significa solo me)
Utilizza ID univoci per ogni oggetto
- (-) altro codice
- (+) database può restituire copie degli oggetti del modello da modificare e solo quando il controllore chiama i metodi del database con gli oggetti del modello copiati che saranno aggiornati

Modifica

C'era una parte importante che ho dimenticato di menzionare: multi-threading e multi-utente A entrambi è sicuramente possibile rispondere con "No". L'applicazione sarà una sorta di un software di pianificazione utente per sostituire l'attuale "pianificazione della carta e penna". Direi che il requisito principale è quello di evitare di iscrivere i lavoratori in vacanza che sono in vacanza o di non dimenticare gli addetti al bilancio che tornano dalle vacanze il giorno successivo. Perché questi sono gli errori che spesso accadono.

Inoltre non c'è bisogno di un'analisi più approfondita degli oggetti del modello e quindi non c'è bisogno di query di database complesse al momento . Pertanto mi piace l'idea di utilizzare XML per creare un'applicazione standalone. O c'è una buona ragione per far esplodere il codice per soddisfare requisiti improbabili?

design java object-oriented-design

posta Thomas 27.06.2014 - 22:53

fonte

1 risposta

Leggi altre domande sui tag design java object-oriented-design

Collegamento a dll con licenza MIT È improprio disporre di un'estensione dell'applicazione per il collegamento a discesa

score 1 · Accepted Answer

Innanzitutto, i consigli:

Utilizza un semplice DB in-proc basato su file come H2 DB o SQLite . Questo è comodo quasi quanto un file XML: puoi continuare a utilizzare lo stesso flusso di lavoro di oggi. Anche a prova di futuro il tuo software in misura.

EDIT: Se ritieni che usare un DB relazionale sia eccessivo, ti consiglio comunque di utilizzare oggetti modello immutabili con un identificatore univoco. In questo modo, solo la tua classe di database può aggiornare lo stato attuale effettivo. Ciò mantiene il processo intenzionale e centralizzato. Elimina le modifiche accidentali dei dati. Ciò renderà anche più semplice la migrazione a un altro DB, se necessario in seguito.

Ora, il "perché":

La tua applicazione è multi-thread o multi-utente? L'utilizzo dell'identità basata su riferimenti può rovinare le parti interne di un oggetto modello se due thread tentano di modificarlo nello stesso momento.

EDIT: Ricorda che il multithreading può avvenire anche in un'applicazione monoutente. Attività asincrone, timer, ecc. Creano tutti i thread e possono accedere al database in modo non sicuro.

Per evitare ciò, puoi utilizzare oggetti Immutable con parametri id univoci. Questo assicura la coerenza per quel singolo oggetto. Tuttavia, thread diversi possono ancora modificare oggetti diversi e farli andare fuori sincrono. Questo distrugge l'integrità del database. Inoltre, un errore o un'eccezione può lasciare le operazioni a metà, causando di nuovo errori nel DB.

Questi sono, naturalmente, i motivi standard per cui un database ACID è essenziale. Le transazioni e il blocco sono forniti solo per questo scopo.

Inoltre, come menzionato da @Birfl, presto colpirai il punto di dover eseguire query complesse sui tuoi dati. XPath può essere d'aiuto, ma dopo dovrai scrivere codice per cercare specifici set di dati. Ciò potrebbe influire anche sulle prestazioni.