leggibilità, manutenzione, e adesione a paradigmi orientati agli oggetti provati sarebbero gli aspetti più importanti della creazione di un'applicazione ColdFusion utilizzando un vero strato servizio di CFC/oggetti, piuttosto che una moltitudine di cfincludes, che è dilettantistica meglio, e può causare incubi alla raccolta dei rifiuti al suo peggio.
leggibilità
Diciamo che avete un cfinclude chiamato _queries.cfm, che includono tutte le chiamate per l'applicazione. Poi, nella parte superiore della pagina dei dipendenti, poco prima dell'uscita tutti i dipendenti, si esegue questa operazione:
<cfinclude template="_queries.cfm" />
<cfoutput query="employeeQry">
Da dove employeeQry viene? È una delle domande in quel modello? Che cosa fa? Devo includere quel modello quando desidero solo i dipendenti? Cosa succede se ha tutte le query nel sito ... devono essere tutti inclusi ogni volta?
Perché non qualcosa di un po 'più leggibile, in questo modo:
<cfset employeeQry = request.model.queries.getEmployees() />
<cfoutput query="employeeQry">
Ahhh, ce ne andiamo. A colpo d'occhio, senza sapere nulla circa le sfumature del vostro sistema, posso identificare subito:
- dove la variabile employeeQry venuto da
- Cosa memorizzato nella cache CFC che io chiamo la query da
- Che sono chiamando una e una sola query, e non di massa compresa una serie di query, nessuna delle quali è necessaria per la pagina.
L'incapsulamento della logica di business in un livello di servizio (CFC) aumenta la leggibilità del codice, che farà la differenza quando si entra nel prossimo argomento.
Manutenzione
Si ottiene una sospensione di una nuova applicazione CF che sei responsabile della, e di aprire la pagina di dipendente di trovare il modello <cfinclude template="_queries.cfm"> sopra.
All'interno che, lo sviluppatore originale lascia un commento che dice qualcosa per l'effetto di: "Cerchiamo di non eseguire tutte le query, facciamo solo esegue una query specifica sulla base di un parametro", e poi si vede qualcosa di simile:
<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>
... così si guarda a questo e pensare, beh ... ho bisogno di modificare la query employeesByDept, in modo da rompere quel modello aperto e trovare:
<!--- employees by department --->
<cfif args.order_by is "ASC">
<cfinclude template="_employeeQryByDeptOnASCOrder.cfm">
<cfelse>
<cfinclude template="_employeeQryByDeptOnDESCOrder.cfm">
</cfif>
... e da questo punto, vuoi spararti in faccia.
Questo è un esempio esagerato, ma è tutto troppo familiare nel mondo ColdFusion; una mentalità hobbista quando si progettano applicazioni di livello Enterprise. Questo "include include include within" l'incubo è qualcosa che gli sviluppatori di CF si occupano più frequentemente di quanto si possa pensare.
La soluzione è semplice!
Un singolo CFC che racchiude la logica aziendale della produzione di query per i dipendenti.
<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>
Ora, si ha un unico punto di riferimento per tutte le informazioni che si desidera produrre quando si interroga il database dei dipendenti, e può parametrizzare/regolare tutto in una volta, senza dover scavare attraverso le montagne del include all'interno comprende all'interno include ... che è ingombrante e difficile da mantenere dritto (anche con un adeguato controllo della fonte).
Esso permette elegante di scrivere una sola riga:
<cfset empQry = request.model.queries.getEmployees() />
o
<cfset empQry = request.model.queries.getEmployeesByDept(14,'DESC') />
e rende il vostro lavoro mantenendo il codice che molto più facile.
L'adesione a Paradigmi Object-Oriented provata
Il tuo capo annuncia che una rockstar Java è unito al team. Sei molto ansioso ed entusiasta di sederti con lui da quando sei stato per la maggior parte bloccato in CF negli ultimi anni, e vuoi avere l'opportunità di mostrargli alcune delle tue cose, e possibilmente imparare da lui.
"In che modo l'applicazione ottiene l'accesso ai dati?" lui ti chiede.
"Oh, abbiamo una serie di query che chiamiamo su varie pagine e, in base ai parametri, ricaveremo diversi tipi di informazioni".
"Bello", dice, "Quindi ... hai un livello di servizio per il modello di oggetti dati, è grandioso."
Non proprio, pensi.E 'solo include all'interno include ... ma lui continua a andare,
"Questo è eccellente, perché una delle cose nuove ne aggiungeremo è un oggetto contraente, che è fondamentalmente un sottoinsieme di dipendenti, ha intenzione di avere alcuni diversi tipi di funzionalità, ma nel complesso agirà in modo molto simile a un Dipendente: andremo avanti e sottoclassi il Dipendente e annulleremo alcune di quelle query ... "
... e ora sei perso . Perché non c'è una sottoclasse di inclusioni. Non c'è eredità in un inclusivo. Un include non ha conoscenza di un dominio o di un oggetto aziendale, o di come dovrebbe interagire con altri oggetti.
Un cfinclude è una comodità per riutilizzare elementi comuni, come un'intestazione o un piè di pagina. Non sono un meccanismo per riflettere le complessità di un oggetto aziendale.
Quando si progetta/costruire/implementare CFC come oggetti che riflettono le entità della vostra applicazione, si sta parlando di un langauge comune: OO. Significa che non ti offre la possibilità di progettare un sistema basato su una struttura comprovata, estende il linguaggio di "OO-ness" ai programmatori in altre tecnologie. Programmatori Java, programmatori C++/C#, ecc ... chiunque abbia una conoscenza ragionevole dello sviluppo orientato agli oggetti parlerà automaticamente la tua lingua e sarà in grado di lavorare con te e il tuo sistema.
Prestate attenzione a questa nota finale: non tutte le applicazioni devono essere orientate agli oggetti. Se il tuo capo vuole che tu faccia un rapido dump XML del tavolo dei dipendenti e lo schiaffo sul sito web - sì, probabilmente puoi rinunciare a un intero modello di oo per quello. Ma se stai costruendo un'applicazione da zero, e mostrerai dipendenti, utenti, reparti, query, ruoli, regole, ticket ... in breve: entità in un dominio, sarà il momento di mettere da parte i compleanni come strumento principale per riutilizzare il codice.
Oh, e PS: Quella piccola nota che ho lasciato in cima alla raccolta dei rifiuti, non è uno scherzo. Ho visto le applicazioni CF compilate in modo errato, quindi Application.cfc chiama cfincludes e, dopo aver collegato CF a JVM that can monitor realtime creation/destruction of objects in the GC, ho visto la memoria come un monitor ECG.
Non valido.
Incredibile. Grazie per l'incredibile dettaglio nella tua risposta. – Antares
In un'altra nota, ci sono altri documenti che descrivono questo che posso leggere per aiutare a convincere il mio capo? – Antares