一直在查看我的前任代码,并经常查看"请求"范围的用法.该范围的适当用法是什么?
代码的任何部分都有几个范围:会话,客户端,Cookie,应用程序和请求.有些不建议以某种方式使用(即在自定义标签或CFC中使用请求或应用程序范围;这是耦合,违反封装原则,并且被认为是一种不好的做法),并且有些具有特殊用途:Cookie保留在客户端上机器作为物理cookie,会话作用域变量是特定于用户的,并在网站上与用户的会话一起到期.
如果一个变量极不可能改变(所有意图和目的都是常量)并且可以简单地在应用程序启动时初始化并且永远不会再次写入,通常你应该把它放到Application范围内,因为这会在每个用户和每个会话之间持续存在.正确实现后,它会被写入一次并读取N次.
Application.cfm中Application变量的正确实现可能如下所示:
请注意,在锁定之前和之后检查应用程序范围中是否存在变量,这样,如果两个用户在应用程序启动时创建竞争条件,则只有其中一个最终会设置应用程序变量.
这种方法的好处是它不会在每个请求上不断刷新这些存储的变量,浪费用户的时间和服务器的处理周期.权衡是它有点冗长和复杂.
通过添加Application.cfc大大简化了这一过程.现在,您可以指定在应用程序启动时创建哪些变量,而不必担心锁定和检查存在以及所有有趣的东西:
有关Application.cfc的更多信息,包括所有可用的特殊功能以及有关使用它的内容和使用方法的每一个细节,我建议在Raymond Camden的博客上发布这篇文章.
总而言之,请求范围在您的代码中随处可用,但这并不一定使得在任何地方使用它都"正确".您的前任可能正在使用它来破坏封装,这可能很难重构.您可能最好离开它,但了解哪个范围是最好的工具,肯定会使您的未来代码更好.
这是一个非常主观的问题,有些人甚至认为在现代ColdFusion应用程序中使用请求范围永远不合适.
有了这个免责声明,让我们定义请求范围是什么以及它在哪里有用.
请求范围是单个ColdFusion页面请求中的绝对全局范围.它不是一个共享范围,如应用程序,服务器,客户端和会话范围,因此不需要锁定使其线程安全(除非您使用CF8的CFTHREAD标记从单个请求生成工作线程).作为一个全局范围,它是一种非常方便的方法,可以将变量保存在请求堆栈中的任何级别,而无需将它们从父级传递给调用者.这是通过旧CF应用程序中的嵌套或递归自定义标记来持久保存变量的一种非常常见的方法.
请注意,虽然许多应用程序使用此作用域来存储应用程序级变量(例如,配置设置),但请求作用域和应用程序作用域之间的差异(有时是微妙的)是同一个请求作用域变量的值可以个别页面请求之间有所不同
我猜你的前任使用这个作用域来方便地设置变量,这些变量需要在封装或嵌套代码单元之间的跳转中存活,而不必明确地传递它们.