将 CFC 文件拆分为多个文件

发布于 2024-10-14 15:44:18 字数 127 浏览 6 评论 0原文

我被要求更新一个旧项目。当我进入 cfc 文件时，它有超过 3000 行代码和超过 100 个 cffunction。我想知道是否可以将 cfc 拆分为多个文件，这些文件的 cffunctions 逻辑分组，而无需更改任何其他页面中的代码。

原文

分享到QQ

分享到微博

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

发布评论

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

不及他 2024-10-21 15:44:18

遇到类似的问题。我创建了新的 cfc，并修改了原始函数以调用新 cfc 中的函数。

例如

 <cffunction name="GetStuff" access="remote" returntype="Struct">
      <cfreturn createObject("component","myNewCFC").GetStuff(argumentCollection=arguments)/>
 </cffunction>

Run into a similar problem. I created the new cfcs and modified the original functions to call functions within the new cfcs.

For e.g

 <cffunction name="GetStuff" access="remote" returntype="Struct">
      <cfreturn createObject("component","myNewCFC").GetStuff(argumentCollection=arguments)/>
 </cffunction>

回复收藏 0 原文

羁客 2024-10-21 15:44:18

重构，重构，重构...

最简单的方法可能是使用 cfinclude 来注入函数（mixin 的）

回复收藏 0 原文

花开雨落又逢春i 2024-10-21 15:44:18

问题意味着有足够的客户端代码使用该对象，如果该对象被分解，则在其他地方更改调用会很麻烦。在这种情况下，将现有对象视为 Facade - 这是一个为某个对象提供统一接口的对象。底层的类层次结构。

产生层次结构的方法是确定那些应该放在一起的功能。每当我遇到这个问题时，函数通常不共享任何状态，而是像静态 java 方法一样，但如果存在共享状态的函数，那么它们是该分组的良好候选者。否则，通常是共享相同输入参数或名称中具有相同措辞的函数（即 saveMyData、loadMyData 等）。

在该示例中，将这些函数复制到新的 CFC 中（例如 MyData） - 此时您可以更改函数名称以消除重复或提高其清晰度（例如 >MyData.load())。返回原始对象（即 BigCFC），删除这些函数的实现，并将调用委托给新创建的 CFC（您可以考虑使新 CFC 成为旧 CFC 的一部分）。因此，它看起来像这样：

<cffunction name="loadMyData">
  <cfargument name="id" type="numeric"/>
  <cfreturn variables.myData.load(arguments.id)/>
</cffunction>

其中 variables.myData 将作为 CFC 初始化的一部分进行设置。

采用这种方法意味着您现有的客户端代码不会受到更改的影响，但仍将所有内容分解为逻辑分组，并定位新代码以使用更细粒度的 CFC。

Question implies there's enough client code using this object that changing the calls elsewhere if the object's broken apart apart is burdensome. In this case treat the existing object as a Facade - that is an object that provides unified interface to an underlying class hierarchy.

The way to approach producing the hierarchy is identifying those functions that should go together. Whenever I come across this problem the functions usually do not share any state, rather they are like static java methods, but if there are functions that share state they are a good candidate for this grouping. Otherwise it's usually functions that share the same input parameters or tend to have the same verbiage in their name (i.e. saveMyData, loadMyData, etc...).

Given that example, copy these functions into a new CFC (e.g. MyData) - at this point you may change the function names to eliminate repetition or improve their clarity (e.g. MyData.load()). Back in the original object (i.e. BigCFC) remove these functions' implementation and instead delegate the call to the newly created CFC (you may consider making the new CFC part of the old's composition). So it would look something like this:

<cffunction name="loadMyData">
  <cfargument name="id" type="numeric"/>
  <cfreturn variables.myData.load(arguments.id)/>
</cffunction>

Where variables.myData would be setup as part of the CFC's initialization.

Taking this approach means your existing client code is unaffected by the change, but still breaks apart everything into logic groupings, and positions new code to use the more granular CFCs.

回复收藏 0 原文

来日方长 2024-10-21 15:44:18

这是一个老问题，我只是随机遇到它，但我想我应该在这里插话，因为这是我必须多次处理的事情。

如果目标只是从代码管理的角度更好地组织事物（而不是说专门减少每个 CFC 中的方法数量），那么我建议将 CFC 分解为多个 CFM 页面并包括它们在 CFC 中。从代码管理的角度来看，您可以将多个函数分组到一个命名良好的 CFM 文件中，这一切都变得更容易处理。调用代码保持不变，因为所有函数仍像以前一样在 CFC 中实例化。

我在 init 方法中使用了一些代码，这些代码自动包含在同一文件夹中找到的所有 CFM 文件，并且我在每个文件夹中放置一个 base.cfc 以及分组的函数。

例如

<cfscript>
    // Set CFC name
    Variables.sCFCName = 'appUtils';
    // Set folder
    Variables.sCFCFolder = GetDirectoryFromPath(GetCurrentTemplatePath());
    // Get CFC files
    Variables.qCFCFiles = directoryList(Variables.sCFCFolder, true, 'query');
</cfscript>

<!--- Init function --->
<cffunction name="init" access="public" returnType="any" output="false" hint="Constructor">
    <cfargument name="DSN" type="string" default="" hint="Datasource" />

    <!--- Set DSN --->
    <cfset Variables.DSN        = Arguments.DSN />

    <cfreturn this />
</cffunction>

<!--- Include CFC files --->
<cfoutput query="Variables.qCFCFiles">
    <cfif Variables.qCFCFiles.type EQ 'file' AND GetToken(Variables.qCFCFiles.name, 2, '.') EQ 'cfm'>
        <cfinclude template="#Variables.qCFCFiles.Name#" />
    </cfif>
</cfoutput>

It's an old question and I just came across it randomly, but I thought I'd chime in here as it's something I've had to deal with on many occasions.

If the goal is simply to organise things better from a code management perspective (rather than say, to specifcially reduce the amount of methods in each CFC) then I'd advocate breaking the CFC down into multiple CFM pages and including them in the CFC. From a code management perspective, you can group several functions into a well named CFM file and it all becomes a lot easier to deal with. The calling code remains the same, as all the functions are still being instantiated in the CFC as before.

I have a bit of code I use in my init methods that automatically includes all the CFM files it finds in the same folder, and I house a single base.cfc in each folder along with the grouped functions.

e.g.

<cfscript>
    // Set CFC name
    Variables.sCFCName = 'appUtils';
    // Set folder
    Variables.sCFCFolder = GetDirectoryFromPath(GetCurrentTemplatePath());
    // Get CFC files
    Variables.qCFCFiles = directoryList(Variables.sCFCFolder, true, 'query');
</cfscript>

<!--- Init function --->
<cffunction name="init" access="public" returnType="any" output="false" hint="Constructor">
    <cfargument name="DSN" type="string" default="" hint="Datasource" />

    <!--- Set DSN --->
    <cfset Variables.DSN        = Arguments.DSN />

    <cfreturn this />
</cffunction>

<!--- Include CFC files --->
<cfoutput query="Variables.qCFCFiles">
    <cfif Variables.qCFCFiles.type EQ 'file' AND GetToken(Variables.qCFCFiles.name, 2, '.') EQ 'cfm'>
        <cfinclude template="#Variables.qCFCFiles.Name#" />
    </cfif>
</cfoutput>

回复收藏 0 原文

~没有更多了~