2013-03-16 31 views
11

我一直在探索構造我的ColdFusion應用程序的不同方法,並且正在尋找一些關於提供應用程序範圍UDF的最佳方法的意見。使用應用程序範圍的UDF擴展ColdFusion

對於我的每個應用程序,我通常會使用一堆額外的功能,這些功能並不屬於任何特定的對象。數據操作的東西大多。 我希望這些函數在我的應用程序中都可用,既可用於CFM模板,也可用於應用程序實例化的CFC。

我看到它有實現這一目標的各種方法,但它們都有各自的侷限性的方式:

  1. 在適用範圍實例化一個基地utils的CFC。 這是我經常使用的方法。所有的函數都可以在應用程序範圍內使用,但是如果我從多個應用程序實例化相同的CFC,那麼它們將分別擁有自己的應用程序範圍 - 這意味着每個函數都必須實例化它們自己的Utils CFC。 這沒什麼問題,但感覺就像我沒有足夠好地封裝CFC。我並不熱衷於從CFC中引用應用程序範圍。

  2. 創建基礎使用CFC並使其他CFC擴展此功能。 這可以正常工作,這意味着CFC可以直接從CFC的THIS範圍引用Utils函數 - 但這意味着Utils函數保存在每個CFC的內存中。 從概念上講,這也不正確,因爲我的其他CFC與Utils CFC沒有任何關係。

  3. 注入我的基礎將CFC用於我的其他CFC。 我一直在玩的另一種方法是在應用程序範圍中實例化我的基礎Utils CFC,但隨後將其作爲對象傳遞給其他CFC中的參數。 這適用於我的概念,併爲封裝。與我將在我的init方法中設置數據源的方式一樣,我也可以對我的UDF執行相同的操作。 這與UDF包含在每個CFC中的問題相同。當我轉儲所有的CFC時,我多次獲得每個UDF--但是當我傳遞一個實例化對象時,我假設它沒有佔用任何額外的內存空間。 如果有人可以證實,這將是有益的 - 我只是假設! 我用這種方法唯一真正的問題是,它似乎有點複雜。

  4. 讓我的應用程序CFC擴展我的Utils CFC。 這是很多框架似乎做的事情。我沒有使用這種方法,但我確信有利弊。

  5. CF從單獨的模板中直接包含我的UDF,直接在Application.cfc中 這在功能上類似於應用程序範圍中的實例化。

  6. 加入我的UDF到服務器的Components.cfc 這在理論上一個偉大的想法 - 我能保持基本utils的一個副本,並確保在服務器上的一切都可以訪問它們 - 但是,如果我想運行跨應用多臺服務器,那麼他們都將需要這些功能。再加上對服務器的任何更新都可能會覆蓋組件。 它只是覺得像黑客攻擊核心 - 我敢肯定,我們可以從痛苦的經驗,所有這些都證明是不好的。

所以 - 我的問題是這樣的: 什麼是在一個優雅的和可重複使用的方式與UDF的擴展CF的最佳做法是什麼?上述任何選項或我沒有想到的東西?

+0

我建議以上都不是。相反,將它們寫入.cfm文件並將它們包含在Application.cfc或需要它們的頁面中。您可能想要擁有多個文件,具體取決於它們是否在不同的主題上。 – 2013-03-16 17:25:30

+0

這不是選項5嗎?問題是其他CFC也沒有封裝 - 在調用函數時,他們必須引用Application範圍。 – 2013-03-16 17:28:12

+0

這不是選項5.您寫的選項5要麼使得udf僅適用於一個應用程序,要麼讓您重複編碼。 – 2013-03-16 17:32:50

回答

1

如果你真的關心結構和保持獨立的東西,甚至不要以單例或繼承來擴展功能。而是通過在運行時/請求see ColdFusion Developer's Guide上附加非組件庫來擴展ColdFusion中的基本功能。這不會神奇地解決所有問題,但至少這是實現通用功能的正確方法。

+0

我不知道我明白。文檔建議我在請求範圍中包含這些函數。從概念上講,我沒有看到與Application範圍中的實例有什麼不同。我的其他氟氯化碳將仍然依賴於它在那裏,必須在他們自己的範圍之外將它們稱爲它們。我看到我不會用這種方法實例化,但有什麼好處? – 2013-03-17 14:59:38

+0

文檔不建議您將您的函數放在請求範圍中。如果你願意,他們會告訴你如何去做。 – 2013-03-18 16:41:25

+0

好的,所以建議我在運行時添加UDF,並且不要將它們包含在CFC中。 當我想在其他CFC內使用其中一個時會發生什麼?如果我必須在僞構造函數中包含包含UDF的.cfm文件,對封裝沒有什麼不好嗎?我認爲將文件的位置作爲init方法的參數會更好 - 在哪一點,將UDF放在實例化的CFC中並將其作爲參數傳遞到哪個位置會更容易? – 2013-03-18 18:17:10