当 CFC 中的 SESSION 变量用于数据源和数据库模式时，如何避免使用这些变量？

Question

我正在尝试重构所有 CFC 以避免使用 SESSION 和 APPLICATION 变量（这不是一件容易的任务）。

但是，在此应用程序中，SESSION 变量在每个数据库调用中使用，因为不同的登录用户可能正在访问不同的数据库和模式：

<cfquery name="qEmployees" datasource="#SESSION.DataSourceName#">
    SELECT *
    FROM #SESSION.DatabaseSchema#.Employees
</cfquery>

我不想经历将这两个 SESSION 变量传递给访问的每个方法调用的麻烦数据库。尤其是这种情况，因为我不想在远程 AJAX 调用中传递 DSN 和架构名称。

对于所有不应该在 CFC 中使用的范围，执行此操作的最佳实践是什么？

Answer 1

我认为，由于数据源确实是变量，我会将其作为可选参数传递到每个函数中，并将默认值设置为变量范围的 dsn 属性。我在 CFC 的构造函数中设置了 DSN 范围内的变量。这样您只需传入 AJAX 调用的 DSN。

<cffunction name="doFoo" access="remote"...>
    <cfargument name="dsn" type="String" required="false" default="#variables.datasource#" />
</cffunction>

我将使用应用程序的会话范围来存储用户 dsn 名称并使用该 var 传递给 AJAX 调用。

Answer 2

您应该创建一个“init”方法作为 CFC 的构造函数。然后，您可以实例化 CFC 并将它们存储在共享范围（很可能是应用程序范围）中。从这里开始，为了通过 AJAX 使用此 CFC，我通常会创建一个远程外观。基本上，这是另一个将直接访问应用程序范围内的 CFC 实例的 CFC。它将实现您需要通过 Ajax 访问的方法，并使用 access="remote" 公开它们，使您的应用程序能够访问实际 CFC 中的 access="public" 方法。在这种情况下，人们普遍认为远程外观可以直接访问应用程序范围作为设计模式的一部分。

一个简单的例子：

example.cfc：

<cfcomponent output="false">
    <cffunction name="init" access="public" output="false" returntype="any">
        <cfargument name="dsn" type="string" required="true" />
        <cfset variables.dsn = arguments.dsn />
        <cfreturn this />
    </cffunction>
    <cffunction name="doStuff" access="public" output="false" returntype="query">
        <cfset var q = "" />
        <cfquery name="q" datasource="#variables.dsn#">
        select stuff from tblStuff
        </cfquery>
        <cfreturn q />
    </cffunction>
</cfcomponent>

在您的 Application.cfc onApplicationStart() 方法中：

<cfset application.example = createObject("component","example").init(dsn = "somedsn") />

remote.cfc：

<cfcomponent output="false">
    <cffunction name="doStuff" access="remote" returntype="query">
        <cfreturn application.example.doStuff() />
    </cffunction>
</cfcomponent>

Answer 3

onRequest 或 onRequestStart 函数中设置数据源变量吗？

<cffunction name="onSessionStart">
    <cfset session.dsn = _users_personal_dsn_ />
</cffunction>


<cffunction name="onRequestStart" >
   <cfset dsn = "#session.dsn#" />
</cffunction>

<cfquery name="qEmployees" datasource="#dsn#">
    SELECT *
    FROM #SESSION.DatabaseSchema#.Employees
</cfquery>

您可以在 Application.cfc等的

不确定这是否有效[未经测试 - 实际上感觉有点草率]
-肖恩

Answer 4

您选择的范围（对于此问题的任何变体，而不仅仅是 DSN）应基于值的生命周期是否与范围的生命周期相同。

在我们的应用程序中，DSN 在应用程序的生命周期中仅设置一次，因此我们有一个在 onApplicationStart 中创建（从文件中解析）的 application.config 结构，其中包含 application.config.dsn

如果您的值确实如此确实会在会话之间发生变化，但不会在会话的生命周期内发生变化，请继续使用会话范围。

如果您的值可能针对任何给定请求而更改，但不会在请求中间发生更改，请将其放入请求范围中。

也就是说，仍然听取 ryan 的建议并添加仅默认为该值的可选参数：灵活总是最好的。

Answer 5

我对此的建议是创建一个基类，然后让需要数据库访问的组件扩展该组件。它不必位于直接父层次结构中，而是位于下线的某个位置。

他们的目标是做两件事，使 cfc 从主程序中抽象出来并使其易于配置。这样就达到了两者的目的。

因此，查询数据库的 CFC 将如下所示：

<cfcomponent extends="DataAccessBase">
<cffunction name="myFunction" access="public" returntype="string">
    <cfquery datasource="#getDSN()#" name="qStuff">select * from table</cfquery>
</cffunction>

上面的关键是 extends="DataAccessBase" 部分。这增加了抽象层，您可以在一个可配置点控制数据访问，但它不依赖于应用程序本身，从而使组件从其实现位置抽象出来。

您的 DataAccessBase.cfc 可能如下所示：

<cfcomponent>
<cffunction name="loadSettings">
    <cfparam name="request.settings" default="#structNew()#">
    <cfparam name="request.settigns.loaded" default="false">
    <cfif request.settings.loaded eq false>
        <!--- load settings from resource bundle etc --->
        <cfset request.settings.dsn     = 'myDSN'>
        <cfset request.settings.loaded  = true>
    </cfif>
</cffunction>
<cffunction name="getDsn" access="public" returntype="string">
    <cfset loadSettings()>
    <cfreturn request.settings.dsn>
</cffunction>

当然，您可以对如何配置和存储设置等变得更加复杂，但这超出了我认为问题的范围。 :)

我认为没有任何理由在每次方法调用时传递 DSN。是的，它有效，但没有必要。这些组件是根据数据结构的内置假设开发的，因此您知道它不会从 addItem() 调用更改为 updateItem() 调用，因此其重复工作意味着额外的故障点。 ：P

有道理吗？