在 ColdFusion Model-Glue 控制器中包含 UDF/CFC 的最佳方式是什么?
我有一些常见的 UDF 和 CFC,我希望将它们提供给我的所有控制器。我正在使用 Model-Glue 3。我想到了几种实现此目的的方法:
- 创建一个基本控制器,其中包含 UDF 的
并实例化 CFC。所有其他控制器都继承自该控制器。 - 将所有 UDF 转换为 CFC,并使用
ColdSpring.xml
将 CFC 转换为 Bean。然后使用ModelGlue.xml
中的beans
属性将其提供给控制器。 - 将 UDF 和 CFC 存储在 helpers 文件夹中并使用 helpers 作用域访问它们。然而,这看起来像是打算由视图而不是控制器使用。
- 创建一个全局
onRequestStart
,它将实例化 CFC 并将它们存储在event
对象中。然后控制器将通过直接从事件
对象中获取CFC来访问它们。
我的问题是,大多数人使用什么方法来为所有控制器提供一组通用的 UDF 和 CFC?
I have some common UDFs and CFCs that I'd like to make available to all my controllers. I'm using Model-Glue 3. I've thought of several ways of doing so:
- Create a base controller that has
<cfinclude>
's to the UDFs and instantiates the CFCs. All other controller inherit from this controller. - Convert all UDFs to CFCs and use
ColdSpring.xml
to make the CFCs into beans. Then make it available to the controller using thebeans
attribute inModelGlue.xml
. - Store the UDFs and CFCs in the helpers folder and access them using the helpers scope. However, this looks like it was intended to be used by a view rather than a controller.
- Create a global
onRequestStart
which will instantiate the CFCs and store them in theevent
object. Then the controllers will access the CFCs by grabbing them directly out of theevent
object.
My question is, what is the method used by most people to make a common set of UDFs and CFCs available to all controllers?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
我会使用上面的选项 2。
对于那些需要辅助方法的对象,我将使用 DI 将辅助对象注入其中。今后这将更加灵活。
我不喜欢带有所有助手的基础对象的想法。原因如下:
如果稍后您想要分解多个 CFC 中的帮助程序怎么办?你不能。根据您拥有的帮助功能的数量以及它可能发展到的数量,这可能会使您的对象变得丑陋。如果有一天您有 50 个辅助函数怎么办?您真的希望您的控制器有 50 个与它们主要关心的问题无关的额外方法吗?
关注点分离。控制者应该担心自己是控制者。它们不应该加载额外的函数,以便它们知道如何格式化字符串。这应该由 StringHelper 或其他东西来处理。
其他两个选项听起来不太好。 Helpers 的范围是什么?
I would use option 2 above.
For those objects that need the helper methods I would use DI to inject a helper object into them. This will be more flexible going forward.
I do not like the idea of a base object with all of the helpers. Here is why:
What if later you want to break up the helpers in multiple CFCs? You can't. Depending on how many help functions you have and how many it could grow into, this could make your objects ugly. What if you someday have 50 helper functions. Do you really want your controllers having 50 extra methods that really have nothing to do with their primary concern.
Separations of concerns. Controllers should worry about being controllers. They should nto be loaded down with additional functions so that they know how to format strings. That should be handled by a StringHelper or something.
The other two options just don't sound great. What is the Helpers scope?