ColdFusion - 何时使用“请求"；范围? [英] ColdFusion - When to use the "request" scope?

问题描述

查看我前任的代码并经常查看请求"范围的用法.这个范围的适当用法是什么?

Been going over my predecessor's code and see usage of the "request" scope frequently. What is the appropriate usage of this scope?

推荐答案

您的代码的任何部分都可以使用多个范围:会话、客户端、Cookie、应用程序和请求.有些不建议以某些方式使用(即在您的自定义标签或 CFC 中使用请求或应用程序范围；这是 耦合，违反了封装原则，被认为是一种不好的做法)，还有一些有特殊用途:Cookie 作为物理 cookie 持久保存在客户端计算机上，Session 范围的变量是用户特定的，并与用户在网站上的会话.

There are several scopes that are available to any portion of your code: Session, Client, Cookie, Application, and Request. Some are inadvisable to use in certain ways (i.e. using Request or Application scope inside your Custom Tags or CFC's; this is coupling, violates encapsulation principles, and is considered a bad practice), and some have special purposes: Cookie is persisted on the client machine as physical cookies, and Session scoped variables are user-specific and expire with the user's session on the website.

如果一个变量极不可能改变(对于所有意图和目的都是常量)并且可以简单地在应用程序启动时初始化并且永远不会再次写入，通常您应该将它放入应用程序范围，因为这会在每个用户和每个会话之间保持它.如果实施得当，它会被写入一次并读取 N 次.

If a variable is extremely unlikely to change (constant for all intents and purposes) and can simply be initialized on application startup and never written again, generally you should put it into Application scope because this persists it between every user and every session. When properly implemented it is written once and read N times.

Application.cfm 中应用程序变量的正确实现可能如下所示:

A proper implementation of Application variables in Application.cfm might look like this:

<cfif not structKeyExists(application, "dsn")>
    <cflock scope="application" type="exclusive" timeout="30">
        <cfif not structKeyExists(application, "dsn")>
            <cfset application.dsn = "MyDSN" />
            <cfset foo = "bar" />
            <cfset x = 5 />
        </cfif>
    </cflock>
</cfif>

请注意，在锁之前和之后检查应用范围内变量的存在，这样如果两个用户在应用启动时创建竞争条件，则只有其中一个用户最终会设置应用变量.

Note that the existence of the variable in the application scope is checked before and after the lock, so that if two users create a race condition at application startup, only one of them will end up setting the application variables.

这种方法的好处是它不会在每次请求时不断刷新这些存储的变量，从而浪费用户的时间和服务器的处理周期.权衡是它有点冗长和复杂.

The benefit of this approach is that it won't constantly refresh these stored variables on every request, wasting the user's time and the server's processing cycles. The trade-off is that it is a little verbose and complex.

添加 Application.cfc 后，这大大简化了.现在，您可以指定在应用程序启动时创建哪些变量，而不必担心锁定和检查是否存在以及所有这些有趣的事情:

This was greatly simplified with the addition of Application.cfc. Now, you can specify which variables are created on application startup and don't have to worry about locking and checking for existence and all of that fun stuff:

<cfcomponent>
    <cfset this.name = "myApplicationName" />

    <cffunction name="onApplicationStart" returnType="boolean" output="false">
        <cfset application.dsn = "MyDSN" />
        <cfset foo = "bar" />
        <cfset x = 5 />
        <cfreturn true />
    </cffunction>
</cfcomponent>

有关 Application.cfc 的更多信息，包括所有可用的特殊功能以及关于什么和如何使用它的每一个小细节，我在 Raymond Camden 的博客上推荐这篇文章.

For more information on Application.cfc including all of the various special functions available and every little detail about what and how to use it, I recommend this post on Raymond Camden's blog.

总而言之，请求范围在您的代码中随处可用，但这并不一定意味着在任何地方使用它都是正确的".很有可能您的前任正在使用它来破坏封装，并且重构起来可能很麻烦.你可能最好保持原样，但了解哪个范围是完成这项工作的最佳工具肯定会让你未来的代码变得更好.

To summarize, request scope is available everywhere in your code, but that doesn't necessarily make it "right" to use it everywhere. Chances are that your predecessor was using it to break encapsulation, and that can be cumbersome to refactor out. You may be best off leaving it as-is, but understanding which scope is the best tool for the job will definitely make your future code better.

这篇关于ColdFusion - 何时使用“请求"；范围?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！