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?

推荐答案

有多个范围可用于代码的任何部分：Session，客户端，Cookie，应用程序和请求。有些不适合以某些方式使用（即在自定义代码或CFC中使用请求或应用程序范围;这是耦合，违反了封装原则，被认为是一个坏的做法），并且一些具有特殊用途：Cookie在客户端机器上作为物理cookie持久化，并且会话范围的变量是用户特定的并且到期

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屋！