Progettazione SQL CRUD Java / Android

Question

Progettazione SQL CRUD Java / Android

Naviga le tue risposte

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

2

Tutti gli SQL nella mia app ...

Dovrei limitarlo alla sua classe speciale? Ad esempio una classe MyDatabase che estende SQLiteOpenHelper e implementa tutte le tabelle create, definisce tutti i nomi delle tabelle, i nomi delle colonne, le query, contiene tutti i metodi CRUD per tutti i miei oggetti, ecc.
O dovrei mettere tutte queste cose negli oggetti reali e avere tutti gli oggetti che implementano un'interfaccia comune come "DatabaseModel" dove tutti i DatabaseModels implementano cose come creare, salvare, eliminare, onCreate, onUpgrade, ecc? Cosa scelgono le persone e perché?
Voglio sapere in che modo la maggior parte delle persone gestisce la creazione / l'aggiornamento. Nel mio caso ho i miei oggetti contengono molti degli stessi membri che fanno nel database SQL. Ad esempio, un oggetto Player potrebbe avere un ID, un nome, un testo su di me, ecc. Tale id corrisponderebbe all'ID auto-incrementato nel database. Ma nell'app, quando si compila per la prima volta i dati per quell'oggetto, non esiste ancora nel database, quindi l'ho impostato di default su un id di -1. Quindi se qualcuno vuole salvare l'oggetto, lo faccio controllare se l'id è negativo, e se è così, lo creo nel database e assegnerò l'oggetto immediatamente al metodo SQL. Altrimenti è un aggiornamento e avrà comunque l'id corretto. È questo che fa la maggior parte delle persone? Questa è una decisione valida?

Se qualcuno risponde, per favore fornisci qualche esempio di cosa intendi.

design sql java crud android

posta Aruka J 08.08.2016 - 06:13

fonte

3 risposte

Leggi altre domande sui tag design sql java crud android

Documento di architettura software di riferimento estendibile: buona idea o no? dove inserire il codice nel modello MVC

score 1 · Answer 1

Se io sono un oggetto nel tuo sistema che deve essere persistente, per favore non spingermi attraverso un po 'tutto sql va qui' God object che a malapena mi conosce.

Inoltre non aspettarti che io usi qualche api a differenza di me per salvarmi. Permettetemi di definire i miei valori e quanto profondamente la mia struttura deve essere copiata. Non chiedermi di sapere nulla sul tipo di persistenza che stai usando. Db strutturato, noSQL, grafico, file flat, non ha niente a che fare con me.

Oh e non ottengo la mia identità da nessun valore ID da ciò con cui mi insisti. Ho ottenuto la mia identità quando sono stato creato.

Tutto ciò di cui dovrei occuparmi è ciò che so. So chi sono. Conosco il mio stato. So cosa dovrebbe morire se muoio. Dammi un api per dire che attraverso e una serie di cose dietro quella api che sanno come parlare a qualsiasi cosa tu mi salvi.

Fai questo e giocherò bene quando uscirà un nuovo tipo di database.

score 0 · Answer 2

Questo è fondamentalmente ciò che faccio, tranne che il mio id è di solito 'nuovo' fino a quando non salvo. Ma solo se è necessario un ID. Se si tratta di un record di transazione in cui non esiste ID univoco per il record (tranne una combinazione di altri valori noti che diventano univoci insieme), provo prima un aggiornamento e, se non riesce, eseguo un inserto.

score 0 · Answer 3

Come contrappunto, mi piacerebbe avere una classe di modello DB. Tale classe consente di implementare codice che può aggiornare automaticamente il database di backup quando si installano versioni successive dell'app. Le classi degli oggetti dati possono ancora fornire metodi alla classe DB in modo tale che sappiano esattamente ciò che è necessario sapere per eseguire correttamente il marshalling dei dati all'interno e all'esterno del DB.