2010-03-17 11 views
5

Una domanda generale su quale opinione di tutti è la memorizzazione di query SQL all'interno di un file di configurazione?Memorizzazione di query SQL in un file di configurazione?

È solo un altro capanno per biciclette?

Cheers, Ben

+0

Puoi ampliare il motivo per cui vorrai. Non penso che questo sia un semplice caso di sì/no e forse esiste un modo migliore e alternativo per ottenere ciò che cerchi. – CResults

+1

Mi spiace solo per chiarire che non ho in mente uno scenario particolare e che stavo semplicemente cercando punti di vista sull'argomento. –

risposta

1

questo è quello che farebbe se si stesse usando iBatis. Non vedo il danno in esso.

E 'certo che batte costruendoli dinamicamente quando non è necessario.

1

No. mai. Seriamente;) Ripulendolo qui al momento.

Provate a guardare BLToolkit - li memorizza in attributi proprio sulla classe astratta generando dinamicamente l'intero codice di accesso sotto. Come usarlo nel file di configurazione, ma senza scrivere o vedere lo stupido codice DAL.

2

Non sembra così male per me, purché soddisfi i requisiti.

Stai cercando di consentire al cliente di visualizzare e modificare le query?

Stai cercando di semplificare lo sviluppo/test?

Preferisco sicuramente questo per incorporare le query nel codice.

Ma c'è il rischio che questo file si gonfia con una miriade di query leggermente diverse (SORT ASCENDING, SORT DISCENDING, SUM (col1) + SUM (col2), SUM (col1) + SUM (col3), ecc.)

1

in quel caso, mi piacerebbe memorizzarli nel db:

  1. renderebbe più difficile per Joe regolare per smanettare con le mie domande e mettere a repentaglio la mia app.
  2. Non è possibile dedurre come archiviare i miei dati.
  3. Le modifiche si rifletteranno automaticamente senza la necessità di "spingere" il file di configurazione.

Ma in realtà, sto estrapolando senza conoscere il tuo scenario attuale. Ma a prima vista, non vorrei che gli altri vedessero come interagisco con il mio schema o come è strutturato.

1

Qual è il tuo ragionamento per posizionarli ovunque ma nel codice? Ho scoperto che il più delle volte le modifiche SQL hanno la stessa velocità del codice, il che significa che se si modifica UserDao.java è probabile che sia necessario modificare sql-statements.properties allo stesso tempo. Detto questo, il codice viene letto molte più volte di quanto non sia scritto, quindi scrivere codice leggibile è fondamentale in una base di codice pulita. Con le istruzioni SQL in un file separato, uno sviluppatore deve cercare altrove per capire quale query viene utilizzata dall'utente, rendendo più difficile la comprensione del codice.

La risposta breve? Lo eviterei se possibile.

Problemi correlati