Come inserire i record di una query in DAO?

Question

Ho scritto un gateway per ottenere un set di risultati dal mio database. Come posso memorizzare ogni riga in un dao separato in modo da poter manipolare ulteriormente ogni record? O posso accedere direttamente al set di risultati per ottenere i record?

Questo è il mio Gateway (tra l'altro, dovrei scrivere la logica condizionale all'interno del cfquery in un cfc separato che estende questo?)

<cfcomponent name="MaterialDao" hint="data access object" output="false">
 <cffunction name="init" hint="constructor" access="public" output="false" returntype="MaterialDao">
  <cfargument name="dsn" type="String" required="true" hint="datasource" />
  <cfset variables.instance.dsn = arguments.dsn />
  <cfreturn this />
 </cffunction>

 <cffunction name="readMaterial" hint="read" access="public" output="false" returntype="Query">
  <cfargument name="district" type="String" />
  <cfset var qReadMaterial = "" />
  <cfquery name="qReadMaterial" datasource="#variables.instance.dsn#">
   <cfif StructKeyExists(arguments,"district")>
   SELECT A.NR, A.BEZ, D.BES, D.STA
   <cfelse>
   SELECT A.NR, A.BEZ
   </cfif>
   FROM  DEK AS D INNER JOIN ART AS A
   ON D.NR = A.NR
   WHERE 0=0
   <cfif StructKeyExists(arguments,"district")>
    AND D.BEZ = #arguments.district#
   </cfif>
   ORDER BY A.BEZ
 </cfquery>
 <cfreturn qReadMaterial />
 </cffunction>
</cfcomponent>

Ho già letto molti articoli e sembra che ci siano opinioni diverse su questo argomento (DAO vs. Gateway, DAO & amp; Gateway ecc.). Qual è la migliore pratica, cosa fanno i professionisti?

Answer 1

I professionisti usano solo un modello per il livello di accesso al database. L'uso sia di DAO che di Gateway è un termine improprio che non sono sicuro da dove sia iniziato, ma sembra esistere solo nella folla di ColdFusion. I modelli DAO e Gateway possono praticamente svolgere la stessa funzione, ma penso che il DAO si adatti di più quando si parla di interazione con il database.

I DAO dovrebbero includere funzionalità per i metodi CRUD oltre a restituire set di record. Poiché CRUD e set di record di base sono altamente ripetitivi, utilizzo un generatore di codice per creare il codice per questa interazione e quindi personalizzare ciò di cui ho bisogno. Questo è un buon posto per la logica condizionale per la selezione dei record necessari.

Come accennato da Aaron, la restituzione di una matrice di oggetti per un set di record nel database non è fattibile in ColdFusion a causa del sovraccarico prestazionale della creazione di oggetti. In genere utilizzo solo la query di base restituita dal DAO nelle mie visualizzazioni. Tuttavia, se la cosa che sto modellando ha bisogno di un comportamento in una vista, inserirò la query in un oggetto usando qualcosa di simile a quello che fa Peter Bell.

Answer 2

Peter Bell ha avuto un'ottima presentazione alcuni mesi fa sul suo rilascio di Iterating Business Object CFC che consente di acquisire più record e iterare su un record alla volta utilizzando questo semplice framework: http://ibo.riaforge.org/ . Fino a quando CF non è un po 'più veloce nel generare oggetti, riciclare una singola istanza di un oggetto e ripopolare le proprietà è probabilmente il migliore. Forse questo può aiutarti a caricare un record alla volta nel tuo DAO.

La logica condizionale può andare nel gateway o in un gestore CFC. In genere, includerei una logica semplice come la logica delineata nel tuo post direttamente nel CFC.

Un po 'di consiglio, potresti voler rendere argomenti.distinct NON richiesti e fare un semplice controllo con if (structKeyExists (argomenti, " distinti ")) {do qualcosa}.

Saluti,

-Aaron Greenlee

Answer 3

Nella nostra azienda abbiamo riflettuto a lungo su questa roba per alcuni mesi, provando il creatore Adobe CF DAO tramite RDS e alcuni altri più vecchi (qualcuno ricorda CFPowerTools?).

Alla fine abbiamo deciso di scrivere il nostro generatore di codice DAO e ho pensato di condividere qui i nostri pensieri. Il motivo per cui abbiamo deciso era perché dovevamo aggiungere suggerimenti di blocco su SQL, volevamo renderlo più efficiente, più sicuro e più pulito.

L'impostazione che abbiamo deciso era quella di creare un oggetto DAO base predefinito (chiamato DAO.cfc ) che generava tutti i DAO 'table' estesi. Tutto ciò che aveva erano alcuni metodi di utilità, ma la cosa fondamentale è che possiamo aggiungere qualsiasi altra funzione in cui abbiamo bisogno di tutti i nostri DAO generati per avere accesso.

Quindi generiamo automaticamente il codice selezionando una tabella dal database (usando l'API di amministrazione CF) e creiamo il [TableName] .cfc DAO con i soliti init, setter e getter, quindi il roba di base CRUD.

Oltre a questo, generiamo anche un [TableName] GatewayBase.cfc e un [TableName] Gateway.cfc . [TableName] Gateway.cfc estende [TableName] GatewayBase.cfc .

Quindi, per un DAO di esempio eseguito su una tabella chiamata "Clienti", i file creati sono:

Customers.cfc /* extends DAO.cfc [not created, already exists] */
CustomersGateway.cfc 
CustomersGatewayBase.cfc /* extends CustomersGateway */

Quindi, l'idea è che il gateway offra un modo per gestire molti record di "clienti": il DAO viene usato quando si tratta di uno solo. Tutti i metodi nel gateway restituiranno generalmente un oggetto query CF. CF è troppo inefficiente per creare enormi matrici di oggetti DAO e nella nostra mente l'oggetto di query in CF è davvero flessibile, quindi siamo felici di usarlo.

Durante la codifica, la sottoclasse CustomerGateway.cfc è l'unica istanziata e utilizzata. Tuttavia, la classe base che estende ha alcune funzioni generiche molto utili che vengono fornite gratuitamente, come getFieldListByProperty () che in base ai parametri passati restituirà determinati campi (ad es. Colonne di tabella) per una determinata proprietà (es. un valore di colonna), ad esempio:

myGateway.getFieldListByProperty(property="status", value="1", fieldList="customerName,customerID", orderBy="createdOn") />

Quella chiamata restituirà i valori 'customerName' e 'customerID' per tutti i clienti con uno stato di 1, ordinati per la data in cui sono stati creati. Il codice viene inoltre rafforzato dall'iniezione SQL e convalidato in modo da generare eccezioni sensate.

Questa funzione fornirà il 99% (speriamo!) delle query multi-record eseguite su una tabella. Se hai bisogno di una query più sofisticata, CustomerGateway.cfc è lì per aggiungere funzioni.

Infine, ti consentiamo di aggiungere funzioni a CustomerGateway solo CFC perché se cambi la tabella dei clienti (diciamo aggiungi una colonna), dovrai ricreare la tabella, e questo sovrascriverà il Customers.cfc e il CustomersGatewayBase.cfc . Tuttavia, il tuo codice personalizzato (se presente) è sicuro nella sottoclasse.

Comunque, questo potrebbe essere leggermente fuori tema, ma sicuramente ho pensato che qualcuno potesse trovare utile la nostra esperienza.