2013-03-16 15 views
11

Ich habe verschiedene Methoden zur Strukturierung meiner ColdFusion-Anwendungen untersucht und bin auf der Suche nach einer Möglichkeit, anwendungsweite UDFs bereitzustellen.Erweitern von ColdFusion mit anwendungsweiten UDFs

Für jede meiner Anwendungen verwende ich in der Regel eine Reihe von zusätzlichen Funktionen, die nicht wirklich in ein bestimmtes Objekt gehören. Hauptsächlich Datenmanipulation. Ich möchte, dass diese Funktionen in meiner gesamten Anwendung sowohl für die Verwendung in CFM-Vorlagen als auch für anwendungsinstanzierte CFCs verfügbar sind.

So wie ich es sehen, gibt es verschiedene Methoden, um dies zu erreichen, aber sie alle haben ihre eigenen Grenzen haben:

  1. eine Basis Utils CFC in den Anwendungsbereich instanziiert. Dies ist die Methode, die ich am häufigsten verwendet habe. Alle Funktionen sind App-weit verfügbar, aber wenn ich denselben CFC aus mehreren Anwendungen instanziiere, dann haben sie jeweils ihren eigenen Anwendungsumfang - was bedeutet, dass jeder seinen eigenen Basis-CFC von Utils instanziieren muss. Es ist nichts falsch daran, aber es fühlt sich an, als würde ich den CFC nicht gut genug einkapseln. Ich bin nicht scharf darauf, den Anwendungsumfang innerhalb des CFC zu referenzieren.

  2. Erstellen Sie eine Basis Utils CFC und machen Sie jeden anderen CFC erweitern dies. Dies funktioniert gut und das bedeutet, dass der CFC die Funktionen von Utils direkt aus dem CIS-Bereich CFC referenzieren kann. Dies bedeutet jedoch, dass die Utils-Funktionen für jeden CFC im Speicher gehalten werden. Es stimmt auch nicht konzeptionell, da meine anderen CFCs keine Beziehung zum Utils CFC haben.

  3. Injizieren Sie meine Base Utils CFC in meine anderen CFCs. Eine andere Methode, mit der ich gespielt habe, ist die Instanziierung meines Basis-Utils CFC im Application-Bereich, aber das Übergeben als Objekt an ein Argument in meinen anderen CFCs. Das funktioniert für mich konzeptionell und für die Kapselung. Auf die gleiche Weise, wie ich meine Datenquellen in meiner init-Methode einrichten werde, kann ich dasselbe mit meinen UDFs machen. Dies hat das gleiche Problem, dass die UDFs in jedem CFC enthalten sind. Wenn ich alle meine CFCs lösche, bekomme ich jede UDF mehrere Male - aber wenn ich ein instanziiertes Objekt übergebe, nehme ich an, dass es keinen zusätzlichen Speicherplatz einnimmt. Wenn jemand das bestätigen könnte, wäre es hilfreich - ich nehme nur an! Das einzige wirkliche Problem, das ich mit dieser Methode habe, ist, dass es ein wenig verschachtelt scheint.

  4. Lassen Sie meine Anwendung CFC meinen Utils CFC erweitern. Dies scheinen viele Frameworks zu tun. Ich habe diese Methode nicht benutzt, aber ich bin sicher, es gibt Vor- und Nachteile.

  5. CFIhre UDFs aus separaten Vorlagen direkt in Application.cfc einbeziehen Dies ist funktionell ähnlich der Instanziierung im Anwendungsbereich der Anwendung.

  6. In meiner UDF an den Server des Components.cfc Es ist eine großartige Idee in der Theorie - ich eine Kopie der Basis Utils halten kann und sicher sein, dass alles, was auf dem Server auf sie zugreifen können - aber wenn ich apps laufen soll über Mehrere Server benötigen dann alle diese Funktionen. Außerdem können bei einem Update auf den Server die Komponenten überschrieben werden. Es fühlt sich einfach an, als ob man den Kern hacken würde - was ich sicher bin, dass wir alle aus bitterer Erfahrung testen können, ist schlecht.

Also - meine Frage ist: Was ist die beste Praxis CF mit UDF in einer eleganten und wieder verwendbaren Art und Weise für die Erweiterung? Irgendwelche der oben genannten Optionen oder etwas, an das ich nicht gedacht habe?

+0

Ich schlage keine der oben genannten vor. Schreiben Sie sie stattdessen in .cfm-Dateien und schließen Sie sie entweder in der Application.cfc oder auf den Seiten, die sie benötigen, aus. Je nachdem, ob sie unterschiedliche Themen behandeln oder nicht, möchten Sie möglicherweise mehr als eine Datei haben. –

+0

Ist das nicht Option 5? Das Problem ist, dass die anderen CFCs nicht gekapselt sind - sie müssten beim Aufruf der Funktionen auf den Anwendungsumfang verweisen. –

+0

Es ist nicht Option 5. Option 5, wie Sie es geschrieben haben, würde entweder die UDFs nur für eine Anwendung verfügbar machen, oder Sie unterliegen der Code-Wiederholung. –

Antwort

1

Wenn Sie wirklich besorgt über Struktur und Dinge unabhängig sind, beginnen Sie nicht einmal mit Singletons oder Vererbung, die Funktionalität erweitern. Erweitern Sie stattdessen die Basisfunktionalität in ColdFusion, indem Sie Ihre Nicht-Komponentenbibliothek an runtime/request, see ColdFusion Developer's Guide, anhängen. Dies löst nicht alle Probleme auf magische Weise, aber zumindest ist dies der richtige Weg, um allgemeine Funktionen zu implementieren.

+0

Ich bin mir nicht sicher, ob ich das verstehe. Die Dokumente schlagen vor, dass ich diese Funktionen in den Anforderungsbereich einbeziehe. Konzeptionell sehe ich nicht, wie sich das im Anwendungsumfang vom Instanziieren unterscheidet. Meine anderen CFCs würden sich immer noch darauf verlassen, dass sie da sind und sie außerhalb ihrer eigenen Reichweite benennen müssen. Ich sehe, dass ich mit dieser Methode nicht instanziiert werden würde, aber was ist der Vorteil? –

+0

Die Dokumentation schlägt nicht vor, dass Sie Ihre Funktion in den Anforderungsbereich aufnehmen. Sie zeigen Ihnen, wie Sie es tun sollten, wenn Sie es wünschen. –

+0

Ok, also der Vorschlag ist, dass ich UDFs zur Laufzeit hinzufüge und sie überhaupt nicht in einen CFC einbeziehe. Was passiert dann, wenn ich eines davon in einem anderen CFC verwenden möchte? Wenn ich die .cfm-Datei, die die UDFs enthält, in den Pseudokonstruktor einbeziehen muss, ist das nicht schlecht für die Kapselung? Ich hätte es besser gefunden, den Speicherort der Datei als ein Argument für die init-Methode zu haben - an welchem ​​Punkt ist es nicht einfacher, die UDFs in einem instanziierten CFC zu haben und das als Argument zu übergeben? –