哪个更适合 UDF：CFC 与 CFM答案

【问题标题】：Which is better for UDFs: CFC vs CFM哪个更适合 UDF：CFC 与 CFM
【发布时间】：2013-09-06 10:23:44
【问题描述】：

我的应用程序的一个文件中有多个逻辑相关的 UDF。

问题是单个文件应该是CFC文件还是CFM文件？为什么？

我参考了以下几个链接，但它们详细说明了如何实施该解决方案。我只想知道哪个更好——CFM 还是 CFC？

How do you organize your small reusable cffunctions?

http://blog.adamcameron.me/2012/07/which-is-better-having-your-methods.html

感谢您的帮助。

【问题讨论】：

在CFC 中我们创建了函数。 CFC 像一个类 (OOP) 一样工作。如果你想使用你的UDF，那么最好使用 CFC，然后将它的对象放入 CFM 并从 CFC 访问这些功能。
谢谢阿扎姆。理论上，这是可以理解的。但是，使用 CFC 而不是 CFM 文件的实际理由是什么？

标签： coldfusion user-defined-functions cfc

【解决方案1】：

“更好”是主观的。如果一组 UDF 都使用您需要在它们之间传递的相同数据，那么它们可能应该被实现为 CFC，以便可以拥有有状态的对象，从而可以将数据和方法封装在它们自己的内存空间中。

如果它们是纯静态方法，那么包含的库文件可能没问题。

包含的 UDF 会单独污染变量范围，而 CFC 实例中的函数是通过一个对象变量访问的，因此更简洁一些。

如果 CFML 有静态方法的概念，我会总是使用 CFC，但由于 CFML没有有静态方法，因此可以将函数库证明为以及 CFC。

就个人而言：我总是使用 CFC。他们只是看起来更有条理，更整洁。

【讨论】：

包含的 udf 文件以什么方式污染变量范围？
Dan - 我认为他的意思只是用函数名称（variables.isThisorthat()）“把它弄得乱七八糟”。

【解决方案2】：

根据我的经验，我更喜欢 CFC。考虑到大多数 UDF 只是实用程序助手，因此它们只需要创建一次。将它们放在 CFC 中意味着您可以将它们加载到应用程序范围中并保留 CFC 实例。 UDF 只会为您的应用程序创建一次。此外，您可以让其他 CFC 扩展此“实用程序”CFC，以便在那里也可以使用 UDF。

现在有了 CFM，只要您包含该模板，就会为该请求再次创建 UDF。这是对真正不需要的东西的额外处理。再加上已经提到的 UDF 污染变量范围的问题是偏爱 CFC 的另一个重要原因。

【讨论】：

如果您采用这种方法并将新的 udf 添加到您的 cfc，我认为您在重新启动应用程序之前无法使用新的 udf。
除了对所表示的实用程序进行一些改进之外，扩展“实用程序”CFC 是非常糟糕的 OO。我不推荐这种做法。