2011-01-27 2 views
1

Меня попросили обновить старый проект. Когда я вошел в файл cfc, у него было более 3000 строк кода и более 100 функций. Мне было интересно, могу ли я разбить cfc на несколько файлов, чьи cffunctions логически сгруппированы без изменения кода на других страницах.Сплит CFC-файл на несколько файлов

ответ

5

Запуск с аналогичной проблемой. Я создал новые cfcs и изменил исходные функции для вызова функций в новых cfcs.

Для например

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

+1 Это правильный подход. – orangepips

+1

просто помните, что создание объекта в Adobe Coldfusion (не знаю, используете вы его или нет) дорого. используя этот подход, вы можете увидеть удар производительности. – rip747

+0

С ХФУ такого размера было бы разумным предположить, что существуют другие проблемы с дизайном, которые вызывают/могут вызвать проблемы с производительностью. Если есть ограничение на пространство решений - IOW, рефакторинг приложения не является соображением - это не плохой подход на данный момент. –

2

Refactor, Refactor, рефакторинг ...

простым способом можно с помощью cfinclude придать функции (подмешать в)

+0

Не было бы моего подхода - '' в объекте CFC мне никогда не нравилось. Но +1 для рефакторинга. –

+0

Это предотвращает работу будущего кода с меньшими объектами - на самом деле цель, если вы думаете об этом. – orangepips

+0

Единственная проблема, с которой вы сталкиваетесь, заключается в том, что при ACF вы потеряли способность перегружать методы в наследовании. У Railo нет этой проблемы. – rip747

2

Вопрос подразумевает, что достаточно кода клиента, используя этот объект, изменяя вызовы в другом месте, если объект сломано обособленно друг от друга является обременительным. В этом случае рассматривайте существующий объект как Facade - это объект, который обеспечивает унифицированный интерфейс для базовой иерархии классов.

Способ подхода к созданию иерархии - это идентификация функций, которые должны идти вместе. Всякий раз, когда я сталкиваюсь с этой проблемой, функции обычно не разделяют какое-либо состояние, скорее они похожи на java-методы static, но если есть функции, разделяющие состояние, они являются хорошим кандидатом для этой группировки. В противном случае это обычно функции, которые имеют одни и те же входные параметры или, как правило, имеют одинаковое словоблудие от их имени (то есть saveMyData, loadMyData и т. Д.).

Учитывая, что пример, скопировать эти функции в новую CFC (например MyData) - на этом этапе вы можете изменить имена функций, чтобы исключить повторение или улучшить их четкость (например MyData.load()). В исходном объекте (т. Е. BigCFC) удалите реализацию этих функций и вместо этого делегируйте вызов вновь созданному CFC (вы можете рассмотреть возможность создания новой части CFC композиции старого). Так это будет выглядеть примерно так:

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

Где variables.myData будет настроен как часть инициализации в ХФУ.

Принимая этот подход, ваш существующий код клиента не изменяется при изменении, но все же разбивает все на логические группы и позиционирует новый код для использования более гранулированных CFC.

+0

Спасибо за ответ. Этот способ будет работать, но для реализации потребуется больше времени. Если бы у меня было больше времени для этого проекта, я мог бы воспользоваться этим подходом. Stil +1 от меня для всестороннего ответа, который ответил на исходный вопрос. Спасибо –

+0

Почему вы думаете, что это займет слишком много времени? Это быстро; он не затрагивает публичный API, поэтому другой код не изменяется. – orangepips

0

Это старый вопрос, и я просто случайно наткнулся на него, но я подумал, что буду звонить здесь, поскольку это то, с чем мне пришлось иметь дело во многих случаях.

Если цель состоит в том, чтобы лучше организовать работу с точки зрения управления кодами (вместо того, чтобы сказать, чтобы уменьшить количество методов в каждом CFC), я бы рекомендовал разбить CFC на несколько CFM-страниц и , включая их в ХФУ. С точки зрения управления кодами вы можете сгруппировать несколько функций в хорошо известный файл 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> 
Смежные вопросы