Come utilizzare efficacemente DAO nel mio server MMO

Question

Come utilizzare efficacemente DAO nel mio server MMO

#1 da (1 voti)
#2 da (0 voti)

0

Sto lavorando a un piccolo gioco multi giocatore per il mio progetto per l'ultimo anno e attualmente sto lavorando al server. È un gioco Tank Battle e ha due entità principali che userò sul lato server che sono

Giocatore (dettagli del giocatore come username, password, currentTank, statistiche)

Tank (Dettagli di un carro armato come velocity, rotationVelocity, Turret)

Torretta (dettagli della torretta come velocità di rotazione, tasso di fuoco, ecc.)

Statistiche (statistiche come totalKills, morti totali, colpi totali ecc.)

Recentemente ho letto di DAO e di come separano le preoccupazioni del database e ho pensato di usarlo nel mio progetto perché il mio progetto ha una buona quantità di dati da perseguire e anche dal fatto che voglio imparare questa tecnica.

Dopo aver letto su DAO mi sono reso conto che sarà necessario mappare il DTO agli oggetti del dominio per la logica aziendale. Dato che avrò un bel po 'di logica su questi oggetti e metodi che non sono realmente necessari su DTO.

Quindi ad esempio mappo:

PlayerDTO - > PlayerObject

Ogni volta che c'è una richiesta da parte del giocatore di muovere il suo carro armato, accodo la direzione in una coda contenuta nel serbatoio del giocatore. (Questo mostra la necessità di avere Oggetto Dominio in quanto non ho bisogno di una coda di movimento sul database ma ho bisogno degli oggetti del serbatoio per mettere in coda i movimenti)

Ora diciamo nel mio MovementService del mio server, faccio il giro dell'elenco PlayerObject (i giocatori registrati) e aggiorno la posizione del tank del giocatore chiamando il player.moveTank () che aggiornerà le sue posizioni in base al movimento accodato in la coda di movimento all'interno di TankObject contenuta in PlayerObject. Capisco fino a questo punto quello che devo fare.

Ora la mia domanda è: come posso salvare PlayerObject sul Database? Devo mapparlo nuovamente su PlayerDTO? Qual è il modo più efficace per farlo?

Per ora ho pensato che quando il giocatore si disconnette, nel mio LogoutService userò il servizio PlayerDAO e otterrò PlayerDTO usando l'ID PlayerObject e aggiornerò i dettagli dell'oggetto e lo salverò nel database ma sento che sarò effettuare chiamate di database aggiuntive solo per ottenere l'oggetto (una chiamata di selezione extra) e per salvarlo piuttosto che aggiornare semplicemente l'oggetto utilizzando la query di aggiornamento.

Ritengo inoltre che solo per l'aggiornamento, diciamo la sua posizione sul database, dovrò utilizzare una query che sovrascriverà tutto. C'è un modo migliore di farlo o lo sto facendo bene?

Nota: non userò nessun ORM nel mio progetto.

P.S. Ho cercato molto ma non ho trovato nessuna domanda simile. So di non aver inserito alcun codice ed è una lunga domanda, ma se qualcosa non è chiaro fammelo sapere.

java dao

posta Sneh 23.10.2015 - 23:40

fonte

2 risposte

0

Invece di mappare i due, potresti avere PlayerObject costruito attorno a PlayerDTO , e tieni semplicemente le informazioni sul giocatore lì. Quando è il momento di salvare, chiedilo indietro dall'Oggetto.

AFAIK funzionerebbe anche con gli ORM, e uno come Hibernate si preoccuperebbe degli aggiornamenti parziali (considerazioni sull'efficienza a parte). Un altro percorso potrebbe essere quello di ricordare "manualmente" (ad esempio nell'oggetto) se solo la posizione è cambiata e in tal caso utilizzare un particolare metodo DAO che prende solo la posizione dal DTO. Ma se stai salvando solo al logout, sovrascrivi tutto.

risposta data 24.10.2015 - 06:58

fonte

Leggi altre domande sui tag java dao

I DTO delle API dovrebbero essere configurati per i clienti o essere universali? Unione di due alberi di ricerca binaria

score 1 · Accepted Answer

Non userò l'ID PlayerObject da nessuna parte in questo. Non vorrei "PlayerDTO usando PlayerObject ID".

L'ID dell'oggetto giocatore dovrebbe essere irrilevante per te. Ovviamente il DAO e specialmente l'ORM (libreria o il tuo codice personalizzato) ne hanno bisogno e lo usano, ma l'oggetto dominio non dovrebbe preoccuparsene. Lo porta solo in giro per l'uso del DAO. Se avessi la mia strada, non sarebbe nemmeno disponibile dall'oggetto dominio tranne forse attraverso la riflessione o un'interfaccia specifica DAO che l'oggetto dominio deve supportare per essere persistibile.

Non sono aggiornato sul pensiero corrente (non ho fatto molto lavoro di database ultimamente), ma nella mia mente i DTO (oggetti di trasferimento dati) servono solo a limitare (o derivare) ciò che viene trasferito a e da un database. Sono più utili quando si utilizza un ORM perché consente all'ORM di rimanere completamente generico lavorando su classi DTO, solitamente prive di comportamento. In sostanza, il DTO funge da mappa tra l'oggetto dominio e le informazioni memorizzate nel database.

Quindi nel tuo caso, vorrei semplicemente consegnare un oggetto dominio giocatore al servizio dao del giocatore. Il servizio dao quindi costruirà un giocatore dto stesso chiedendo l'oggetto dominio giocatore che ha ricevuto, o chiederebbe all'oggetto dominio giocatore di fornire un'istanza dto del giocatore, e quindi passerà l'istanza del giocatore dto al codice che costruisce le query ed esegue contro un database. Potrebbe essere un ORM o il tuo codice.

Se il servizio dao costruisce il dto, o l'oggetto dominio, è un compromesso. Preferisco che il servizio dao costruisca il lettore dto per essere utilizzato dal codice di accesso al database (personalizzato o ORM). Il motivo è che l'oggetto dominio non dovrebbe preoccuparsi di alcuna persistenza, dovrebbe essere in grado di supporre che sarà sempre in giro. Il servizio dao è il luogo naturale per tutte le logiche di persistenza: dove archiviare qualsiasi cosa (db, file, registro), cosa deve essere memorizzato (mappatura del dominio su dto) e come deve essere memorizzato (mappatura di dto alle tabelle e campi, strutture xml o altro) e quali traduzioni devono essere eseguite (ad esempio, la conversione di un'enumerazione nei valori per un campo di caratteri in una tabella).