ColdFusion - 何时使用“请求” 范围?

发布于 2024-07-04 12:22:52 字数 48 浏览 11 评论 0原文

一直在检查我前任的代码并经常看到“请求”范围的用法。 这个范围的正确用法是什么?

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

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

乖不如嘢 2024-07-11 12:22:53

我一直在编写我公司的框架,该框架将用于为我们的网站提供支持。

我使用请求变量来设置其他 CFC 可用的某些数据,我必须这样做,以便数据在整个应用程序中可用,而不需要不断传入数据。 老实说,我相信使用 request 和 application 只要它是静态函数组件,那么就不应该有问题。 我不确定我的想法是否错误,但一旦我发布框架,我们就会看到。

I've been writing my company's framework that will be used to power our site.

I use the request variable to set certain data that would be available to the other CFC's I had to do this so the data would be available throughout the application, without the need to continually pass in the data. I honestly believe that using request , and application as long as its a static function component then you should not have a problem. I'm not sure if I am wrong in my thinking with this but once I release the framework we will see.

过度放纵 2024-07-11 12:22:53

好吧,我只是想对你的代码发表评论。 如果我看起来很疯狂,请原谅我。 但您已经在一开始就验证了 structKeyExists。 既然您知道这将是真的,那么再进行一次检查就没有意义了。 所以我的版本是这样的......但这只是我。


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

好吧。

Okay, I just wanted to comment on your code. Please forgive me if I seem crazy. But you already verified that the structKeyExists in the beginning. Since you know it's going to be true, it wouldn't make sense to run another check. So my version of it would be this... But thats just me.


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

Alright.

甜警司 2024-07-11 12:22:53

这是一个非常主观的问题,有些人甚至认为在现代 ColdFusion 应用程序中使用请求范围永远都不“合适”。

排除了该免责声明后,让我们定义请求范围是什么以及它在哪里有用。

请求范围是单个 ColdFusion 页面请求中的绝对全局范围。 它不是共享作用域,如应用程序、服务器、客户端和会话作用域,因此不需要锁定来使其线程安全(除非您使用 CF8 的 CFTHREAD 标记从单个请求生成工作线程)。 作为全局范围,这是一种非常方便的方法,可以通过请求堆栈中的任何级别保留变量,而无需将它们从父级传递给调用者。 这是在旧版 CF 应用程序中通过嵌套或递归自定义标签来保存变量的一种非常常见的方法。

请注意,虽然许多应用程序使用此范围来存储应用程序级变量(例如配置设置),但请求范围和应用程序范围之间的巨大(有时是微妙的)区别在于,同一请求范围变量的值可以各个页面请求之间存在差异。

我猜想您的前任使用此作用域作为一种方便设置变量的方法,这些变量需要在封装或嵌套代码单元之间的跳转中生存,而无需显式传递它们。

This is a very subjective question, and some would even argue that it is never "appropriate" to use the request scope in modern ColdFusion applications.

With that disclaimer out of the way, let's define what the request scope is and where it would be useful.

The request scope is the absolute global scope in a single ColdFusion page request. It is not a shared scope, like application, server, client, and session scopes, so locking is not necessary to make it threadsafe (unless you spawn worker threads from a single request using CF8's CFTHREAD tag). As a global scope, it is a very convenient way to persist variables through any level in the request's stack without having to pass them from parent to caller. This was a very common way to persist variables through nested or recursive Custom Tags in older CF apps.

Note that while many applications use this scope to store application-level variables (configuration settings, for example), the big (and sometimes subtle) difference between the request scope and the application scope is that the value of the same request-scoped variable can differ between individual page requests.

I would guess that your predecessor used this scope as a means to conveniently set variables that needed to survive the jump between encapsulated or nested units of code without having to pass them around explicitly.

暮年 2024-07-11 12:22:52

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

如果变量极不可能更改(对于所有意图和目的都是恒定的)并且可以在应用程序启动时简单地初始化并且不再写入,那么通常您应该将其放入应用程序范围,因为这会在每个用户和每个会话之间保留它。 如果正确实现,它会被写入一次并被读取 N 次。

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

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

请注意,在锁定之前和之后都会检查应用程序范围内变量是否存在,因此,如果两个用户在应用程序启动时创建竞争条件,则只有其中之一他们最终将设置应用程序变量。

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

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

<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 的更多信息,包括所有可用的各种特殊函数和每个小函数有关什么以及如何使用它的详细信息,我推荐这篇文章在雷蒙德·卡姆登的博客上

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

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.

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.

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.

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>

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.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文