legibilidad, el mantenimiento, y la adhesión a paradigmas orientados a objetos probados serían los aspectos más importantes de la construcción de una aplicación ColdFusion usando una verdadera capa de servicio de CFC/objetos, en lugar de una multitud de cfincludes, que es un aficionado a mejor, y puede causar pesadillas de recolección de basura en su peor momento.
legibilidad
Digamos que usted tiene una llamada cfinclude _queries.cfm, que incluyen todas las llamadas para su aplicación. A continuación, en la parte superior de la página de los empleados, justo antes de la salida de todos los empleados, esto se hace:
<cfinclude template="_queries.cfm" />
<cfoutput query="employeeQry">
dónde employeeQry viene? ¿Es una de las consultas en esa plantilla? ¿Qué hace? ¿Debo incluir esa plantilla cuando solo quiero empleados? Lo que si tiene todas las consultas en el sitio ... es lo que todos necesitan ser incluidos cada vez?
Por qué no algo un poco más legible, como esto:
<cfset employeeQry = request.model.queries.getEmployees() />
<cfoutput query="employeeQry">
Ahhh, ahí vamos. A primera vista, sin saber nada acerca de los matices de su sistema, puedo identificar de inmediato:
- donde la variable employeeQry vino de
- Qué caché CFC Estoy llamando a la consulta desde
- Que soy llamando a una y solo una consulta, y no en masa, incluyendo una serie de consultas, ninguna de las cuales es necesaria para la página.
La lógica de negocios encapsulante en una capa de servicio (CFC) aumenta la legibilidad de su código, lo que marcará la diferencia cuando pase al siguiente tema.
Mantenimiento
Se obtiene una bodega de una nueva aplicación CF que está a cargo de, y abre la página de los empleados a encontrar la plantilla <cfinclude template="_queries.cfm"> anteriormente.
Dentro de eso, el desarrollador original deja un comentario diciendo algo en el sentido de: "No vamos a ejecutar todas las consultas, vamos a ejecutar una consulta específica en base a un parámetro", y luego se ve algo como esto:
<cfswitch case="#param#">
<cfcase value="employee">
<cfinclude template="_employeeQry.cfm">
</cfcase>
<cfcase value="employees">
<cfinclude template="_employeesQry.cfm">
</cfcase>
<cfcase value="employeesByDept">
<cfinclude template="_employeesByDept.cfm">
</cfcase>
</cfswitch>
... así que a ver esto y pensar, bueno ... tengo que modificar la consulta employeesByDept, por lo que la plantilla grieta que se abre y se encuentra:
<!--- employees by department --->
<cfif args.order_by is "ASC">
<cfinclude template="_employeeQryByDeptOnASCOrder.cfm">
<cfelse>
<cfinclude template="_employeeQryByDeptOnDESCOrder.cfm">
</cfif>
... y por esta punto, quieres dispararte en la cara.
Este es un ejemplo exagerado, pero es muy familiar en el mundo de ColdFusion; una mentalidad de aficionado al diseñar aplicaciones de nivel empresarial. Esta pesadilla de "incluir dentro de incluir dentro" es algo que los desarrolladores de CF enfrentan con más frecuencia de lo que piensas.
¡La solución es simple!
Una sola CFC que encapsula la lógica de negocio de la producción de consultas para sus empleados.
<cfcomponent>
<cffunction name="getEmployees" returntype="query">
<cfquery name="tmp">
select employeeID, name, age
from employees
</cfquery>
<cfreturn tmp />
</cffunction>
<cffunction name="getEmployeesByDept" returntype="query">
<cfargument name="deptID">
<cfargument name="order_by" required="false" default="ASC">
<cfquery name="tmp">
select employeeID, name, age
from employees e
inner join empToDept etd on (e.employeeID = etd.employeeID)
where etd.deptID = #arguments.deptID#
order by name #iif(arguments.order_by is 'asc',de('asc'),de('desc'))#
</cfquery>
<cfreturn tmp />
</cffunction>
</cfcomponent>
Ahora, usted tiene un único punto de referencia para toda la información que desea producir cuando se consulta la base de datos de los empleados, y puede parametrizar/ajustar todo a la vez, sin tener que excavar a través de las montañas de los incluye dentro de incluye dentro incluye ... que es engorroso y difícil de mantener recto (incluso con un control de fuente adecuado).
de forma elegante le permite escribir una sola línea:
<cfset empQry = request.model.queries.getEmployees() />
o
<cfset empQry = request.model.queries.getEmployeesByDept(14,'DESC') />
y hace que el mantenimiento de su trabajo el código que mucho más fácil.
La adhesión a paradigmas orientados a objetos probadas
Su jefe anuncia que una estrella de rock Java se ha unido al equipo. Estás muy ansioso y emocionado de sentarte con él, ya que durante los últimos años has estado atrapado principalmente en la FQ, y quieres una oportunidad para mostrarle algunas de tus cosas, y posiblemente aprender de él también.
"Entonces, ¿cómo accede la aplicación a los datos?" él te pregunta.
"Oh, tenemos una serie de consultas que llamamos en varias páginas, y en base a los parámetros, vamos a tirar diferentes tipos de información."
"agradable", dice, "Así que ... usted tiene una capa de servicio para el modelo de objeto de datos, que es grande."
No realmente, que piensan.Es sólo incluye dentro incluye ... pero él sigue adelante,
"Eso es excelente, porque una de las cosas nuevas se irán sumando es un objeto contratista, que es básicamente un subconjunto de Empleado, que va a tiene algunos aspectos diferentes de la funcionalidad, pero en general se comportará como un empleado. Seguiremos adelante y subclase Empleado, y anularemos algunas de esas consultas ... "
... y ahora estás perdido . Porque no hay subclases ni incluyen. No hay herencia en una inclusión. Una inclusión no tiene conocimiento de un dominio o un objeto comercial, o cómo se supone que interactúa con otros objetos.
Un cfinclude es una conveniencia de reutilizar elementos comunes, como un encabezado o un pie de página. No son un mecanismo para reflejar las complejidades de un objeto comercial.
Al diseñar/construir/implementar los CFC como objetos que reflejan las entidades de su aplicación, que está hablando un langauge común: OO. Significa que no le ofrece la capacidad de diseñar un sistema basado en una estructura comprobada, sino que extiende ese lenguaje de "OO-ness" a los programadores de otras tecnologías. Programadores Java, programadores C++/C#, etc ... cualquiera que tenga un conocimiento razonable del desarrollo orientado a objetos hablará automáticamente su idioma y podrá trabajar con usted y su sistema.
Tenga en cuenta esta nota final: No todas las aplicaciones deben estar orientadas a objetos. Si su jefe quiere que prepare rápidamente un volcado XML de la tabla de empleados y lo abra en el sitio web, sí, probablemente pueda renunciar a un modelo completo de oo para eso. Pero si está creando una aplicación desde cero, y va a contar con empleados, usuarios, departamentos, consultas, roles, reglas, tickets ... en resumen: entidades en un dominio, será hora de dejar de lado los cfincludes como su herramienta principal para reutilizar el código.
Ah, y PD: Esa pequeña nota que dejé en la parte superior sobre la recolección de basura - no es una broma. He visto aplicaciones CF incorrectamente construidas, por lo que el Application.cfc sí llama cfincludes, y después de enganchar CF hasta un JVM that can monitor realtime creation/destruction of objects in the GC, he visto mirada memoria como un monitor ECG.
No es bueno.
Increíble. Gracias por el increíble detalle en su respuesta. – Antares
En otra nota, ¿hay otros documentos que detallen esto que pueda leer para ayudar a convencer a mi jefe? – Antares