¿Cómo poner registros de una consulta en DAO?

Question

He escrito una puerta de enlace para obtener un conjunto de resultados de mi base de datos. ¿Cómo almaceno cada fila en un dao separado para poder manipular cada registro más? ¿O puedo acceder al conjunto de resultados directamente para obtener los registros?

Esta es mi puerta de enlace (por cierto, ¿debería escribir la lógica condicional dentro del cfquery en un cfc separado que extienda este?)

<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>

Ya he leído muchos artículos y parece que hay diferentes opiniones sobre este asunto (DAO vs. Gateway, DAO & amp; Gateway, etc.). ¿Cuál es la mejor práctica, qué hacen los profesionales?

Answer 1

Los profesionales usan solo un patrón para la capa de acceso a la base de datos. El uso de DAO y Gateway es un nombre inapropiado que no estoy realmente seguro de dónde comenzó, pero parece que solo existe en la multitud de ColdFusion. Los patrones DAO y Gateway pueden cumplir prácticamente la misma función, pero creo que el DAO se ajusta más a la factura cuando se habla de la interacción de la base de datos.

Los DAO deben incluir la funcionalidad para los métodos CRUD más los conjuntos de registros de retorno. Como CRUD y los conjuntos básicos de registros son muy repetitivos, utilizo un generador de código para crear el código para esta interacción y luego personalizar lo que necesito. Este es un buen lugar para la lógica condicional para seleccionar los registros que necesita.

Como Aaron mencionó, devolver una matriz de objetos para un conjunto de registros en su base de datos no es factible en ColdFusion debido a la sobrecarga de rendimiento de la creación de objetos. Normalmente solo uso la consulta básica devuelta por el DAO en mis vistas. Sin embargo, si lo que estoy modelando necesita algún comportamiento en una vista, entonces pondré la consulta en un objeto usando algo similar a lo que hace Peter Bell.

Answer 2

Peter Bell tuvo una gran presentación hace unos meses sobre su lanzamiento del CFC Iterating Business Object que le permite tomar múltiples registros e iterar sobre un registro a la vez utilizando este marco simple: http://ibo.riaforge.org/ . Hasta que la FQ sea un poco más rápida en la generación de objetos, reciclar una sola instancia de un objeto y repoblar las propiedades es probablemente la mejor opción. Quizás esto pueda ayudarlo a cargar un registro a la vez en su DAO.

La lógica condicional puede ir en el Gateway o en un Manager CFC. Por lo general, incluiría una lógica simple como la lógica descrita en su publicación directamente en el CFC.

Un pequeño consejo, es posible que desee hacer los argumentos. NO se requiere distinción y hacer una verificación simple con if (structKeyExists (argumentos, " distintivo ")) {hacer algo}.

Saludos,

-Aaron Greenlee

Answer 3

En nuestra empresa, pensamos mucho sobre estas cosas durante unos meses, probando el creador DAO de Adobe CF a través de RDS y algunos otros más antiguos (¿alguien recuerda CFPowerTools?).

Decidimos al final escribir nuestro propio generador de código DAO y pensé en compartir nuestros pensamientos aquí. La razón por la que decidimos fue porque necesitábamos agregar sugerencias de bloqueo a SQL, queríamos hacerlo más eficiente, más seguro y más limpio.

La configuración que decidimos fue crear un objeto DAO base predefinido (llamado DAO.cfc ) que todos los DAO 'table' generados extendieron. Todo lo que tenía eran unos pocos métodos de utilidad, pero lo importante es que podemos agregar cualquier otra función a la que necesitemos todos nuestros DAO generados para tener acceso.

Por lo tanto, generamos código automáticamente seleccionando una tabla de la base de datos (usando la API de administración de CF) y creamos el [TableName] .cfc DAO con el init, setters y getters habituales, por lo que el cosas crudas básicas.

Además de esto, también generamos un [TableName] GatewayBase.cfc y un [TableName] Gateway.cfc . [TableName] Gateway.cfc extiende [TableName] GatewayBase.cfc .

Entonces, para un DAO de muestra ejecutado en una tabla llamada 'Clientes', los archivos creados son:

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

Entonces, la idea es que la puerta de enlace proporciona una forma de manejar muchos registros de 'Cliente': el DAO se usa cuando se trata de uno y solo uno. Todos los métodos en la puerta de enlace generalmente devolverán un objeto de consulta CF. CF es demasiado ineficiente para crear matrices masivas de objetos DAO y, en nuestra opinión, el objeto de consulta en CF es realmente flexible, por lo que nos complace usarlo.

Al codificar, la subclase CustomerGateway.cfc es la única instanciada y utilizada. Sin embargo, la clase base que extiende tiene algunas funciones genéricas muy útiles que son gratuitas, como getFieldListByProperty () que, en función de los parámetros pasados, devolverá ciertos campos (es decir, columnas de la tabla) por una determinada propiedad (es decir un valor de columna), por ejemplo:

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

Esa llamada devolverá los valores 'customerName' e 'customerID' para todos los clientes con un estado de 1, ordenados por la fecha en que se crearon. El código también está reforzado contra la inyección de SQL y validado, por lo que se lanzan excepciones sensatas.

Esta función proporcionará el 99% (¡esperamos!) de las consultas de registros múltiples que realice en una tabla. Si necesita una consulta más sofisticada, entonces el CustomerGateway.cfc está allí para que pueda agregar funciones.

Finalmente, le permitimos agregar funciones a CustomerGateway CFC solo porque si cambia la tabla de clientes (por ejemplo, agregue una columna), deberá volver a crear la tabla, y que sobrescribirá el Customers.cfc y el CustomersGatewayBase.cfc . Sin embargo, su código personalizado (si lo hay) está seguro en la subclase.

De todos modos, esto podría estar un poco fuera de tema, pero seguro que pensé que alguien podría encontrar nuestra experiencia útil.